In #12903 we merged a PR fixing the handling of the default width (0.8) when bar (barh, broken_barh) is called with unitized data (I was among the PR approvers; see also #13187 as followup). Briefly, the idea is to support both unitless and unitized widths, so that one can do

bar([dates])  # default width: 0.8
bar([dates], width=[timedeltas])  # or single timedelta
bar([categoricals])  # default width: 0.8
bar([categoricals], width=[unitless])  # or single scalar

The main trickiness is that the default width is unitless (0.8), but one can also pass a unitful width, so it's not clear how to add it to the unitized x; moreover, note that the unit of x can either correctly handle addition (time + timedelta), or not (categoricals, which need to go through the converter first). So the end design is something like

try:
    dx = deunitize(orig_x + orig_dx) - deunitize(orig_x)
except ...:
    dx = deunitize(orig_dx)

where orig_x and orig_dx are the user inputs, either unitized or deunitized.

However, I now feel like this is not really looking at the problem under the right angle: if the user input is unitized, what's the chance that 0.8 "deunitized-units" is a reasonable default width? It is rather low, I would guess. Instead, it would seem that the intent of the default would/should be "0.8 times the spacing between the bars" (in the common case of evenly spaced bars).

Hence, a solution may perhaps be to change the interpretation of a unitless width in the case of unitized data, to have it mean (e.g.) a fraction of the (mean) spacing between the bars (i.e. (max(x) - min(x)) / (n - 1)). Note that because bar did not support unitized data up to now, there are no backcompat concerns.

Mostly @jklymak I guess. Allowing myself to mark this as release critical mostly so that we don't have to go through a painful deprecation period if we agree on this, but feel free to untag.