This is actually a proposition for a behavior change caused by a bugfix.

I have a project dealing with a metaclass factory and the next thing in the TODO list was to add multiple inheritance support.
For my surprise, I tried and there was no metaclass conflict on Python 2.7... I've been developing on Py3.2 and now on Py3.3 an it couldn't obviously choose one of the metaclass to use.

I found this(http://hg.python.org/cpython/rev/c2a89b509be4) commit saying the metaclass calculation was fixed on some special cases (I think it is because of the __new__ method on the metaclass). Py3.1 and inferior are not affected.

----

The thing is: My metaclasses are smart enough to produce the right behavior so the "bug" doesn't bother me as long as this bugfix never gets backported.

For Python 3.2+, the solution requires some more code/knowledge for the user:

If I have this class diagram for "Obj", "A" and "B":


              Obj[type=M]                        M
              /        \             ->         / \
        A[type=MA]  B[type=MB]                 MA MB


then, I want to create C:

    class C(A, B, metaclass=something):
        pass

Where "something" cannot be neither "MA", "MB" or "M" because of metaclass conflict.

but if 

    something = lambda *args: M(*args)

I can call finally call my "smart" metaclass to solve the problem.

----

Now the proposition:

It is possible for the metaclass to have some special attribute (e.g. __call_me_maybe__ = True) so Python knows it can deal with these special cases and avoid the user to explicitly use the `metaclass` parameter?

So
    class C(A, B):
        pass

Would call "MA" because of the special attribute inherited from "M" and it would know how to deal with the B class. 
If it can't do it with some X class, just return NotImplemented or other thing so the `TypeError: metaclass conflict...` will finally be shown.