Dealing with `matrix` in this fashion is not really an additional overhead to allowing lists or other sequences as inputs: you just always use `np.asarray()` on the inputs. If everyone did this, though, `matrix` would be useless since it would disappear whenever you passed one to a function. scikit-learn accepts this; it doesn't care about supporting `matrix` users except to transparently consume their data. It also doesn't have many functions that one would really use in expressions, so it's not much loss for `matrix` users. But there are a lot of other functions that do need to output `matrix` objects to be useful to `matrix` users, and this is difficult so few people do it right. That's why the status quo sucks. You can choose between having an operator for matrix multiplication by using the `matrix` type or having the full range of the community's code available to you. You can't have both. And just to be clear, there is nothing about this situation that depends on the implementation details of `numpy.matrix`. Subclass or not, all of these issues remain as long as you have two types that you want to interoperate.