Frankly I don't see this as high priority. Sure if you want to add it, go ahead but keep it short. Using these class names outside the library is unusual and I think the documentation doesn't even mention them in any guide or example. So the usage will be very low and I expect anyone depending somewhat on the library internals to do proper testing or at least read the change log thoroughly before upgrading a dependency.

As for the compatibility aliases, they don't bother me at all where they currently live. So there's no planned time frame to remove them.

Any (active developed) API will evolve over time. It is wise to have a strategy of how to introduce new methods and classes, how to deprecate and then finally remove obsolete ones:

1. When do we inform the user of deprecation?
2. When do we remove the deprecated methods and classes?

I guess each of these bullet points need someone to put in the work. If you're up to it, make some suggestions. So far we simply don't have a "grand plan" about deprecation, so I'd handle it lazily until it gets annoying somewhere. I love software that just keeps working and doesn't break other code arbitrarily. Keeping the old names is the simplest approach to that as it requires no effort really.