Current status: Tim is currently not actively involved in Python development and no one who is active is enthusiastic about the proposal.

Your proposal is to add dependency injection to the initializer for the 4 diff classes by adding 6 new parameters. I will comment on the proposal itself below.  But first...

Your initial message in support of the proposal was about as weak as possible: "it would be possible to ...".  Lots of things are possible. For instance, we could add a Socket class replacement parameter to all stdlib functions and classes that use socket.Socket (and this has been requested in at least one case).  However, only a few changes actually get done.  Recognizing this ...

Your later message gave one use case: Bazaar's experiments with an alternate implementation.  To me, this example is still inadequate justification for a change. We agree that cut-and-paste is bad (though not terrible for one-off experiments).  That is why Python allows dynamic patching ('monkeypatching') of modules and Python-coded classes as an alternative (though subclassing is often better for classes).

import difflib
# either
class MyDiff: pass  # not really ;-)
# MyDiff might or might not subclass SequenceMatcher
difflib.SequenceMatcher = MyDiff
# or
def f(self, *args): pass  # again, not really
difflib.SequenceMatcher.somemethod = f
# either way, use difflib functions with alternate matcher.

I consider subclassing + dynamic patching an adequate solution* for the one use case you mention and likely other uses.  So I am inclined to reject the proposal as 'unnecessary'.  (If multiple people were routinely monkeypatching difflib like this, I might change my mind.)

* A context manager can be used to make the monkeypatching temporary and therefore local in effect. The following works.

@contextlib.contextmanager
def mp(ob, attr, new):
    old = getattr(ob, attr)
    setattr(ob, attr, new)
    yield
    setattr(ob, attr, old)


As for the proposal itself: you mention possible API alternatives.  I am more concerned about expanding our responsibility and corresponding test requirements.  If you monkeypatch the module, then you are responsible for the results.  If we add what amount to monkeypatching parameters, then we become responsible.  We would have to make sure that the requirements for replacements are adequately defined and design at least one non-trivial replacement and run all the appropriate tests with that replacement.  Your patch does not do this.  I would not want to do this. We would also have to be prepared to maintain the expanded definition of the classes.

Extending the mandate of the four classes from "work reasonably well with the builtin diff engine" to "work reasonably well with any 'similar' diff engine passed in by a user" is not as trivial as implied by the patch.

For a simple function like filter, the requirement for the function parameter is simple.  It must be a predicate with respect to the items yielded by the iterable arguments.  That means returning False or True and never raising when applied to each item.  It is easy to create alternatives such as lambda x: False, lambda x: True, lambda x: bool(x), and lambda x: x < 0, and test with appropriate iterables.

I hope this explains a bit why function parameters are routine in Python while class parameters are much less common.