Re the OO part - there are a few problems with the class idea. Firstly, how do class and package relate? Are they synonymous? Can you have one inside the other?

On a somewhat higher level, what if the class construct isn't the best way to do OOP.

Some newer languages (Go and Rust) have avoided having a class construct (but still support some flavour of OOP).

And going back much further, we find works like the GOF book, which was based around two principles

• Program to an 'interface', not an 'implementation'
• Favor 'object composition' over 'class inheritance'

So instead of just copying a sub-optimal construct that some other languages copied from others, maybe we ought to step back and look for better abstractions?

My own lengthy contemplation has led to a prototype of what such abstractions could look like. Mic provides Interfaces (which support Eiffel-like contracts) as a primary abstraction, and Implementations as a secondary abstraction.

I worry that what gets implemented would be "weaker" than what can already be achieved using libraries.