This doesn't work for categorical in "height". (0 + 'cat') has no meaning.

I'll be honest, I don't understand why height=['cat', 'dog', 'cat'] is something anyone would want.

OK, this works, but not happy with all the try/except clauses.

Just to summarize the issues:

1. bottom = datetime, height = timedelta: the unit checker needs to check height+bottom (=datetime). Currently it just sees timedelta, which is converted to floats and dates are not used.
2. bottom = 0, height = []: we can't add 0+[]: proposal here is just to pass bottom like before.
3. bottom = 0, height = ['cat', 'dog']: can't add 0 + ['cat', 'dog']: proposal here is to keep the old behaviour.

diff --git a/lib/matplotlib/axes/_axes.py b/lib/matplotlib/axes/_axes.py
index f80efddfe1..89e79d35a8 100644
--- a/lib/matplotlib/axes/_axes.py
+++ b/lib/matplotlib/axes/_axes.py
@@ -2391,12 +2391,12 @@ class Axes(_AxesBase):
 
         if orientation == 'vertical':
             self._process_unit_info(
-                [("x", x), ("y", height)], kwargs, convert=False)
+                [("x", x),  ("y", height), ("y", y)], kwargs, convert=False)
             if log:
                 self.set_yscale('log', nonpositive='clip')
         else:  # horizontal
             self._process_unit_info(
-                [("x", width), ("y", y)], kwargs, convert=False)
+                [("x", width), ("x", x), ("y", y)], kwargs, convert=False)
             if log:
                 self.set_xscale('log', nonpositive='clip')
 

I think this works just as well (and perhaps can even be simplified to remove the horizontal/vertical dependence on the difference for unit behavior.

It would perhaps be odd if we were using the returns here, but this should, I belive, use the units from the first of the two with the same axis that has an associated Converter (_process_unit_info will not override units/converter if they are set, and won't set it if raw floats are passed)

There is nothing preventing passing multiple tuples for the same axis, as far as I can tell.

That does seem to work, and passes all the tests.

OTOH I worry about the axis latching onto the wrong unit (eg in height) if for instance someone makes a timedelta converter, which has been talked about quite a bit. In that case, the timedelta converter would be used because height is passed in first, but we really meant to check datetime+timedelta.

The point is "height" really should be in delta units, whereas bottom should be in absolute units. However, we have allowed 0 + 'cat', which is clearly in categorical units - or at least we have tests that do this, whether they are sensible or not is open to intepretation (and we allow empty lists, which we could probably just short circuit at the at top, so thats not really a problem)

If we swapped the order (i.e. did ("x", x), ("x", width) instead of ("x", width), ("x", x)) is that sufficient?

I think it may still have delta problems, but not sure it would have any more delta problems than than the try/excepts implemented here...

With try/except paths as implemented here:

If y is float (e.g. 0) and height is timedelta, then the try except will try to do 0 + <timedelta> and fail (unsupported operand types) and pass the timedelta directly to process_unit_info.

With passing both separately to process_unit_info:

The raw float value will not assign units, the timedelta will. This is the same end result.

As for categoricals, I can't think of a sensible way to have your categories be a "delta", as is needed for height with non-zero baseline.
I think allowing the ax.bar([1,2,3], ["a", "b", "c"]) case that is in the tests is relatively reasonable. A bar graph where you are cartoonizing your y axis with string labels that have no formal mathematical relationship (but perhaps have an order).

Current main already breaks if you try to pass categoricals to both bottom and height, though not in _process_unit_info (rather in _convert_units or somehow set_linewidth (‽)) I don't think either of the suggestions would change that being disallowed (and don't really think that is a problem)

OK - note that 0 + np.timedelta64(10, 'h') is OK though.

Even so, it still returns a timedelta64, not a datetime, so even that is still in delta form.

New implementation follows @ksunden suggestion, which works well, and as discussed on the call, I agree is semantically correct.