Hm, should SignalWatcher itself be abstract? I guess probably so.

However technically you could do:

class MyElement extends LitElement {...}

customElements.define('my-element', SignalWatcher(MyElement));

The test below "class returned from signal-watcher should be directly instantiable if non-abstract" seems to suggest this is possible as is.

The tests show an interesting behavior. While I would've expected returning an abstract class here would always result in an abstract class that's non-instantiable, it seems it's still instantiable if the class provided to the mixin is non-abstract?

So then the reason for the addition of abstract in this line is to preserve the abstract behavior if the class provided to the mixin is also abstract. I don't know if that's something we strictly need to preserve, but seems unlikely to be a problem.

customElements.define('my-element', SignalWatcher(MyElement)); is possible and tested by this PR here.

The tests show an interesting behavior. While I would've expected returning an abstract class here would always result in an abstract class that's non-instantiable, it seems it's still instantiable if the class provided to the mixin is non-abstract?

This is accurate. If the passed in class is non-abstract, then the resulting class from the mixin is non-abstract. This is due to the type signature of the mixin, which takes in Base: T, and returns T. So the return type matches the exact class passed in. The mixing-in of SignalWatcher is not reflected in the type system.

So then the reason for the addition of abstract in this line is to preserve the abstract behavior if the class provided to the mixin is also abstract.

This is required in order to pass in an abstract class with abstract members. Otherwise, within the mixin we'd get a type error suggesting that abstract methods/fields need to be implemented. By marking the mixin class abstract, the abstract methods do not need to be implemented by the mixin. We get to have our cake and eat it too, because the abstract mixin class is not reflected in the return type as mentioned above. So a concrete class being passed in can still be directly newed.

Thank you for the excellent explanation!

The test below "class returned from signal-watcher should be directly instantiable if non-abstract" seems to suggest this is possible as is.

The tests show an interesting behavior. While I would've expected returning an abstract class here would always result in an abstract class that's non-instantiable, it seems it's still instantiable if the class provided to the mixin is non-abstract?

So then the reason for the addition of abstract in this line is to preserve the abstract behavior if the class provided to the mixin is also abstract. I don't know if that's something we strictly need to preserve, but seems unlikely to be a problem.