Coupling: unnamed classes must live in the unnamed package.
The rationale for this is that the only thing you can do with an unnamed class is run it from the command line, and it may well be the only class in your program. If you're going to the effort of organizing into packages and distributing a JAR, you're well outside the use case for an unnamed class.
Another way to phrase this coupling is: distribution -> requires named classes.
Coupling: public is only optional on main methods in the unnamed package.
This is largely a forced move, because giving the launcher additional privileges to open classes in existing packages would allow running of "main" methods that are not allowed today, which seems a compromise to the accessibility model. Situating the launcher in the unnamed package seems an entirely unsurprising thing, and again, people don't (or shouldn't) distribute code in the unnamed package.
Another way to phrase this coupling is: distribution -> requires public entry points.
Coupling: instance main requires a no-arg constructor.
Pretty hard to imagine getting around this one; seems intrinsic to the "instance main" feature.
Coupling: unnamed classes don't get constructors.
This one could be decoupled, though I'm not sure it helps.
Coupling: unnamed classes must have a main.
If we interpret unnamed as really unnamed, the only thing you can do with an unnamed class is run it via the launcher, so not having a main would be silly.
