Since vertical is the default, should it be the fallback position? Or will this error out if an orientation besides horizontal or vertical is provided?

I just followed the convention that is used in mpatches.StepPatch (in patches.py) to which orientation is passed. The current behavior is that any value that is not "vertical" will be interpreted like "horizontal".

One can of course change this behavior, but that was not my intention in this PR.

I hear that that's a separate discussion. I'm also wondering why stairs has to do unit processing if it's being done inside the patch creation code. Is it cause of:

https://github.com/stiglers-eponym/matplotlib/blob/6bcc38ad70066c391e327884af8bf917975cfd3f/lib/matplotlib/axes/_axes.py#L7855-L7863

And if so can that information be populated from patch.get_data()?

The issue is that Artists are currently not responsible for data limit handling. For the patch itself, this is done in add_patch() through _update_patch_limits(). But I suspect this cannot handle the sticky edges of the baseline, and it would not be reasonable to special case this there. Therefore, the baseline handling is left directly to stairs(), which implies the need for unit conversion.

The long-term solution will be #30342. I don't think a partial rewrite to handle the current limitations in another way is reasonable. Therefore, the proposed minimal fix is the way to go.