Let me describe two ways that I understand our design approaches to differ.

Your code module system has one function that determines which code can break abstractions. The code module that sealed some particular object is able to unseal it by virtue of the module that sealed it. I think this is a good design pattern that C++ provides by virtue of names of private fields being out of scope except for the code that defines the object behavior.

Keykos & EROS achieve this unsealing limitation by limiting the distribution of an unsealer capability, which is particular to some given type. In Keykos it is called the domain creator at one abstraction level, and the factory builder's key at a higher level. The ability to unseal is thus dynamic but the general practice is to distribute this capability in a static manner. An exception to this might be when the unsealer is invoked explicitly by a programmer from a command line to debug a misbehaving object.

Another emphasis is upon stable behavior of software that is built upon unstable foundations, but perhaps this is my misunderstanding of your emphasis. My rhetorical response is that IBM dominated a large part of the software industry for several decades by providing a virtually stable foundation even when the real foundation was very fluid. The variety of 360s and later 370s were extraordinarily stable, well defined and compatible even thru several fundamental hardware revolutions. They did less well in making uniform the variety of operating systems that they provided. A design goal of Keykos was to extend the stable and uniform portion of the technology to a higher level of abstraction.

There may be only rhetorical differences between the systems, if that.