The issue with com.sun./sun. packages is that they're visible/accessible in general. Can you point to an example involving extending from an internal class? An issue involving using an internal class is not related to final/open.
should we design a language (or tool) for workarounds or proper usage?
Closed by default also doesn't feel like designing for proper usage.
Closed by default in standalone project: No impact. If I want to extend a class and realise it's not open, I assume it's because the developer didn't think and left it the default. I add the open keyword.
Open by default in standalone project: If I want to extend a class and realise it's final, I assume there's a good reason for it because someone chose to add the non-default final keyword and find out why. If there is no reason for it, I remove the final keyword.
All this achieves is changing the default to something which requires either very little effort to fix in a standalone project, or much annoyance in a library. I'm willing to bet that most developers won't think about whether a class needs to be final when creating it, leaving most classes in Kotlin libraries final for no real reason.