Hi Matt,
I’m sorry to hear that you have had issues upgrading from config version 2 to 2.1. I’m on the team that implemented the 2.1 config, and I’d like to share some of the context around the breaking changes that we made.
One thing to note is that config version 2.1 is opt-in, and is not required for pipelines.
We arrived at what is now “config version 2” after a bunch of iteration, where we built the 2.0 platform using early versions of the 2.0 config ourselves, and later in a closed beta with some partners. All the time we were iterating on the config format. When we finally called CircleCI 2.0 “released”, the config file format had a sizeable amount of backwards compatibility shims in it under the hood, from where we had iterated on the config schema. This lead to us having some really poor error messages for invalid config, because we had some hand-written schema checks which allowed a lot of questionable yaml to build. The 2.0 release was iterative, where we on-boarded more and more customers over time, with a closed beta, and open beta, etc, so we never had a single “release” where we would have been able to define the “finished” config schema (and break the builds of customers who had adopted 2.0 early).
When we started the project to add the features that we added in config version 2.1 (commands, parameters, orbs, etc), we found that we couldn’t add these new features into config 2.0 in a manner which was backwards compatible without compromising the design, or in a way that produced useful error messages. We decided to make a clean break, and bump the config version to 2.1.
Config version 2.1 is a lot more strict about what it accepts than 2.0 was, especially in regards to additional keys that are not expected. In particular, in config 2.0 you could add extra keys nearly anywhere in the YAML document, and our parser would ignore them. This lead to cases where a typo would be silently ignored. When we looked at the data, we found that the resource_class was the most commonly misspelled key. The pitfall here is that if you add resource_class: large to your config file but you misspell resource, our config validation for 2.0 would ignore the key, and your job would run on the medium resource class.
The other area that we tightened up was the names that we allow – we restricted the character set and length of a bunch of fields in the config file. The one that has affected you here was job names. We added a lot of restrictions on the contents or orbs, since they are stored in a registry, passed through an API, processed in the command line tool, etc. Since jobs can be contained within orbs, we restricted what a job can be called, and the restriction is global, and affects all jobs in the config file.
So that’s the context 
In your case, do you know what the error message produced was? I’ve added a job with a : in the name, and when I run circleci config validate in the CLI tool I get the following:
marc@blaster ~/dev/circleci/circle $ circleci config validate
Error: ERROR IN CONFIG FILE:
[#/jobs/job-with-a-:-in-the-name] string [job-with-a-:-in-the-name] does not match pattern ^[A-Za-z][A-Za-z\s\d_-]*$
Did you get a similar error message? Echoing the regex back to the user as part of the error message is not the most clear way for us to convey the issue here. Do you have any thoughts on what error message that we could show to make it clear to you what the problem is?
Thanks,
Marc
If you were designing this, what information specifically would have been most helpful?