Mixins Web IDL syntax "conflict"

mixins.md

Discussion of the potential keyword mixin

Web IDL (which is used for writing web specs) would like to introduce a concept of "mixins", which work by adding properties and methods to the mixin target. Currently this is accomplished by

interface MixinTarget { };

[NoInterfaceObject]
interface Mixin { };
MixinTarget implements Mixin;

This pattern (relying on the combination of implements and [NoInterfaceObject]) is fragile and strange for various reasons, so we'd like to replace it with a dedicated construct. The current proposal is to use the syntax:

interface MixinTarget { };

mixin Mixin { };
MixinTarget implements Mixin;

Having a dedicated mixin keyword which creates dedicated "mixin types", instead of using [NoInterfaceObject] and having the mixins be a special case of the more general "interface types", will improve web specs a lot.

Our concern is: if ES comes up with its own concept of mixins that ends up being different, will this be confusing? For example, something like Justin proposes here (which follows examples in Dart and Ruby), which creates a class hierarchy. It would be a big shame if JavaScript ended up using a mixin keyword or contextual keyword to mean something like that, retroactively making a bunch of Web IDL-using specs confusing for web developers to read.

To be clear, there's no real conflict here; the keywords used in Web IDL are not in any real collision with those in ES. We just want to avoid potential confusion.

What I'd like to get a sense of from the committee is: if mixins are likely to happen in ES, what kind of syntactic form would ES end up using, so we can avoid collision? Maybe we can also use this as a bridge to discussing mixins in general.