Problem

I realized that subplot_mosaic() is quite nice even to create single row or single column layouts if you were previously going to stuff the result of subplots() in a dict anyways (or use hardcoded indices, in which case a dict may be more robust if you may (in some later iteration of the code) add axes somewhere in the middle).

(Side points: Also, this avoids running into the subtle bug, when writing axs = subplots(n), of the case n = 1 where axs is squeezed into a single axes (yes, I know, the fix is to pass squeeze=False...) Single column is slightly trickier than single row (subplot_mosaic([[name] for name in names])) but heh.).

However, subplot_mosaic() does not allow axes sharing. Yes, I've even argued against it in the original PR on the grounds of "too complicated" (#16603 (comment))...

Proposed Solution

... but we could at least support the simplest case(s), as in subplots(): sharex/sharey=True/"all" (this is completely unambiguous: share all axes -- "all" is a synonym from subplots() that we probably want to keep for consistency), and possibly "row"/"col" (I'd say two axes (which may have various spans) are in the same row for sharing purposes if they both begin on the same row and end on the same row, which seems the most useful definition)? We should be careful, when checking for True, to actually check for that value (or 1, or np.bool(True)), and not for general truthiness, so that we don't get boxed in later if we decide we do want to support passing in complex sharing specs (e.g. via dicts, as proposed in the original PR thread). (I'm still against that complexity, at least for now...)

Labeling as good first issue as I don't think there's too much complexity or API design space here, although we still need to decide whether this is a good idea or not.

Additional context and prior art