Without digging through the discussion, can you explain this deprecation path? I'd have thought that changing the behaviour of the returned object was worse than explicitly returning a different class.

I don't have a very strong opinion here, but do you have another proposal? (Preferably without rehashing the whole discussion at #11358...)
Note that I believe having a noisy deprecation (to force people to explicitly opt-in the new handler, perhaps via a rcparam) is not realistic because it will impact a huge number of people using legends even though only a tiny minority (those accessing the underlying artists to modify it) will actually be affected by the API change; moreover, in all likelihood, they were actually relying on private attributes anyways (#11358 (comment), #20552).

I thought the alternative would be to return a new class (ideally a subclass of the old one). It would only break people explicitly relying on the different behaviour. To get the old behaviour they would get the old class back.

Btw I agree that it's not worth a noisy deprecation cycle.

Do you mean calling the new handler e.g. HandlerLine2DMonolithic (and registering that one by default) and keeping the old one as HandleLine2D but not registering it? Sure, I don't have a strong preference here.

I don't know enough of the details to have a strong preference either

OK, I'll let other reviewers chime in then.

So the main difference is returning [legline, legline_marker] (old) vs [legline2d] (new) in create_artists(). A real deprecation with warning might be possibly. We'd need to return [obj1, obj2], where obj1 and obj2 fulfill the old API and obj1 fulfills the new API. That could possibly be resolved by returning Line2DHandleList(legline2d), where Line2DHandleList is like [legline2d, legline2d] but warns whenever the second element is accessed. I don't think we need to proxy the line objects themselves because legline2d is a superset of legline functionality (The only breakage would be that formerly you could have done legline.set_marker() which now would have a different effect, but that's quite artificial).

class Line2DHandleList(Sequence):
   def __init__(self, legline):
       self._legline = legline

   def __len__(self):
       return 2

   def __getitem__(self, index):
       if index != 0:
           _api.warn_deprecated(...)
       return [self.legline, self.legline][index]

Off the top of my head, that should cover all realistic use cases of the present API.

Do you mean calling the new handler e.g. HandlerLine2DMonolithic (and registering that one by default) and keeping the old one as HandleLine2D but not registering it?

I suppose nobody is using these classes by name. So, which one is the HandlerLine2D is not particularly important. Therefore I vote to switch the naming. Having HandlerLine2D in the long run is better.

If people need to keep compatibility with older versions, they can do:

from matplotlib.lines import Line2D
try:
    from matplotlib.legend_handler import HandlerLine2DCompound
    mlegend.Legend.update_default_handler_map({Line2D: HandlerLine2DCompound()})
except ImportError:
    pass

which should be document in the API change note.

Sure, it's a bit wordy because the normal machinery shouldn't trigger the deprecation, but it's done now.