Yep, this is a clear backwards compatibility issue if you're using escapeIllegalJcrChars() for example to map arbitrary strings to JCR names. An upgrade shouldn't break that mapping.
Unfortunately changing the mapping again now would just create another backwards compatibility issue. So my recommendation would be to either resolve this just as Won't Fix with a recommendation to use Sascha's workaround from above, or to add a new escapeIllegalJcr10Chars() method for use by clients that rely on the older mapping. In either case a client code change is needed for the 1.x to 2.x upgrade in cases where the client relies on this mapping.