If the config.xml file format is considered internal, Jenkins shouldn't have APIs that expose it. That's not internal.

Here's our use-case: Developers have certain golden paths for creating specific types of applications. We have templates in Jenkins for each type. Developers run a build to create a new application. We grab the config.xml from the template, update it to use values specific to the new job, then post that config.xml to Jenkins to create the job.

Switching to the two plug-ins mentioned is a big under-taking. We have to learn Groovy and/or export our entire Jenkins configuration as YAML and write automation to apply it. Given enough warning, we could do it. This feature should be rolled back, then announced that it's coming with instructions on how to migrate to some way of managing job configurations without touching config.xml files. Then the config.xml file format can become internal and you can change to 1.1 if you want and this could get refiled as "allow job configuration to include control characters".

Aaron Jensen, here is what we ended up doing. https://paste.ofcode.org/3aPEN9YyVDEcCGM2JmX8zw

You must note that most editors that work fine with XML 1.0 can't parse XML 1.1. After more than a decade successfully using the free MS utility XML Notepad for all XML tasks I may have to look for another editor. How much of a demand there was for this change?

Just to add, as far as I can tell you only need 1.1 if you've got control characters in names (i.e. of tags and attributes).
Surely if people are putting them in their configuration it's in text content, where 1.0 works just fine with standard escapes.

Not only does .NET not support xml 1.1 but neither does Firefox, nor any of my editors.