I think this is expected behaviour and I'm not sure if we really can do anything about it. This happens because when the constraints are first computed the xtick on the right hand side of the axis horizontally overspills the axis bounding box, so constrained layout adds a bit of space. The axes gets redrawn, the axis is larger, and now the tick label fits.

I don't think there is anything to directly be done about this. I think you could take the tick label out of the layout, but that is a bit fiddily. If you want the axes to always exactly touch, then I'm not sure I'd bother using constrained layout.

Btw it maybe could be more clear, but this is the case covered by caveat 2 here https://matplotlib.org/stable/users/explain/axes/constrainedlayout_guide.html#other-caveats

This happens because when the constraints are first computed the xtick on the right hand side of the axis horizontally overspills the axis bounding box, so constrained layout adds a bit of space. The axes gets redrawn, the axis is larger, and now the tick label fits.

I'm not sure I follow why this should be nondeterministic between identical executions. I do think the zero-space result is the correct one (following from what I stated under "additional information"), but even if it isn't I don't see why the result should be nondeterministic.

I think you could take the tick label out of the layout, but that is a bit fiddily.

As an aside, I would like to know how to do this (using set_in_layout on the tick labels' Text instances didn't work) - but I asked about it on discourse because it's a separate question that I'm not yet sure is a bug.

This is a complicated interplay of our tick system being too customizable, being too lazy, and IMO, some weird cross-ownership of the calculation of tight bounding boxes. In order to calculate the bounding box of the Axes, the Spine is the one that handles the tick lines (which is odd to me, since the Axis owns the Ticks):

Ticks are generated lazily, and copy properties from the initial tick:

This means that the Spine will sometimes calculate a bounding box for a inward tick, and sometimes one for an outward tick, depending on which random tick it used.

Indeed, setting the rcParams in my example globally rather than as a context appears to ensure determinism. Also helps explain the inconsistent behavior I was observing more generally (since I was using rc contexts to facilitate testing, whereas I normally set a style globally).

Many thanks for digging into it (and addressing it so quickly)!

@QuLogic, would your observations explain why calling set_in_layout(False) on all tick labels has no effect on the constrained layout result?

I'm actually struggling to get set_in_layout to have any effect on any artist at all. Even ham-fistedly applying it to all axes' children has no effect, e.g.,

%matplotlib inline

import matplotlib.pyplot as plt
rc = {
    "xtick.direction": "in", 
    "ytick.direction": "in",
    "figure.constrained_layout.use": True,
    "figure.constrained_layout.h_pad": 0,
    "figure.constrained_layout.w_pad": 0,
    "figure.constrained_layout.wspace": 0,
    "figure.constrained_layout.hspace": 0,
}
plt.style.use(rc)

fig, axes = plt.subplots(2, 2, figsize=(6, 4), sharey=True, sharex="col")
for ax in axes.flat:
    ax.set_title("title")

for ax in axes.flat:
    for artist in ax.get_children():
        artist.set_in_layout(False)

Let me know whether to open a new issue. I'm really struggling to study the issue in more detail because, e.g., I can't figure out how to properly draw bboxes on figures. Copying this color_boxes method and using it as in those tests draws boxes that only cover ~the lower-left quadrant of the axes, e.g.,

import matplotlib.pyplot as plt
fig, ax = plt.subplots()
bbaxis, bbspines, bbax, bbtb = color_boxes(fig, ax)

yields

The bad bboxes are because you are drawing in pixel co-ordinates, but Matplotlib doubles the pixels for retina displays. I wouldn't dig code out of the tests and expect it to work on arbitrary code. In particular transform=None is not going to work for that situation.

As for taking everything out of layout - that may not work as not everything checks the in_layout setting when calculating the tightbboxes. One would have to track all the elements down and then decide if it makes sense to allow them to be excluded. It is possible that the axes elements have never been excluded.

The bad bboxes are because you are drawing in pixel co-ordinates, but Matplotlib doubles the pixels for retina displays.

Argh, thanks, I set that in my jupyter configuration so many years ago I completely forgot about it.

I wouldn't dig code out of the tests and expect it to work on arbitrary code. In particular transform=None is not going to work for that situation.

Do the tests set some global configuration that's not evident in the files themselves, or is just my own config to worry about? I scoured the repo, issues, discourse, and google for other up-to-date solutions before realizing the tests should be as authoritative as it gets.

As for taking everything out of layout - that may not work as not everything checks the in_layout setting when calculating the tightbboxes. One would have to track all the elements down and then decide if it makes sense to allow them to be excluded. It is possible that the axes elements have never been excluded.

Does the docstring for get_tightbbox (and this line in get_default_bbox_extra_artists) not suggest that they are meant to be excluded?

Someone would have to check the code paths for getting bounding boxes, which are somewhat convoluted.