> From that I assume there's no technical issue with, say, a concrete widget extending more than one mixin itself extending Widget (for instance, Widget's implementation of lifecycle methods wouldn't be called more than once)

Right, C3MRO handles this.

> But I'm still wondering about the OOP semantic: by extending Widget, the mixin would clame being a Widget, isn't it? Since the class/module name doesn't contain anymore the word "mixin"

You could also argue that Widget falsely claims that it's a widget, because it's not called WidgetBase or WidgetMixin.  But we went round on naming classes, discussing various pros and cons (like excessive typing) and ended up with https://docs.google.com/document/d/1qjU9hm1HUnZIv051yC01VS81EmciA27GuqOkQPXmY3E, specifically the part that says:

> Public classes and that must not be instantiated because they are just parent classes for implementations SHOULD be suffixed by Base (e.g. CalendarBase) *when they need to differentiate themselves from the actual user accessible implementation (e.g. Calendar).*