The premise is sound. Java can not remain forever tied to eternal backwards compatability. The nomenclature and deprecation stuff, all well and good. Those changes are not substantial and will help the language. But on several of the substantial changes, you missed.
There are good reasons why Java needs a different windowing system than Swing. Perhaps the AWT is not it, but if not, then maybe the SWT should replace it. Whatever the case, Swing, for all its nicities, is never going to compete with native windowing components. For many applications, developers *need* a windowing system that renders using the platform's native components, not just one that approximates the native system with a look and feel. Java should maintain a facility for doing this. Swing is great for many applications, but too many people write off Java desktop application development b/c of bad experiences with the Swing GUIs. I've had to fight against this perception problem at jobs in the past.
For that matter, the legacies of the 1.0 event model are still very useful when you are developing custom components. If you need to create a GUI element that isn't supported by the provided components, it really helps to have access to those methods. For everyone else, they never have to touch those methods, so I don't see how that imposes any penalty on them.
The class loader problem you point to is intractable, short of having to qualify classes not just by package but by build (big no).
And I can't *believe* you would even give the suggestion that checked exceptions be eliminated a mention. I don't care *how* good Thining In Java is, Bruce was and is a fool for advocating that. But go read his article and my (and others') responses to it.
The previous comment by someone re: XML is well put. XML does have too much baggage. It is great for many applications, but it is by no means the best way to skin every cat.