I'm going to ignore the fact that this proposal lacks any kind of
motivation, any kind of argument for why this feature should exist,
any discussion of similar features/how to achieve similar effects
using existing tools, any investigation of other languages with
similar features, or basically any thought beyond "here's an idea I
had; we should do that!" Instead, I am going to focus on the "merits"
of the proposal.

It makes a mockery of the type system and even if this were a
well-formed proposal, it should be abandoned on that basis.

The text of this proposal treats an "interface" as a thing that is a
type. It is not presented as a new kind of entity; it is a type. This
is why you have to explicitly forbid things like virtual functions,
member variables and the like, because the proposal treats an
"interface" as just a new way to write a type. The "interface"
inherits from a type and therefore inherits everything in the "base"
type.

That is not acceptable.

The reason why "casting" a class to a derived class that it definitely
is not is UB is because it breaks the strict aliasing rule. There is
no derived class object instance there, so pretending that there is
one is nonsense. That this "works" on various compilers is completely
irrelevant to this fact. It is UB behavior because it makes no sense
in terms of the object model.

The ability to manufacture one type "around" an existing one is not
without foundation; the whole "implicit object creation" thing works
on that basis. However, IOC only works for object *creation*; it does
nothing for getting rid of them, which is where the problems really
start here.

If you manufacture the "interface" type around some existing object,
what is to stop someone from manufacturing a *different* interface
type around that same object? So... which is it? An object cannot have
two types; that is again antithetical to how the C++ object model
works.

The only way for any of this to make sense is to use a concept-map
approach. The "interface" is not a type; the object retains its
original type. An "interface" therefore becomes something that isn't a
type; it's an interface. And code which uses an interface can *only*
use the members of the interface, not any members of the type it is
interfacing with. That is, using an interface is like template
instantiation.

Trying to hack the type system for this is just not acceptable as an approach.