Still an issue for me on Cargo 3.5.1. Enabling the new flag remedied our endless page-save/timeout issue. The issue emerged for us on switching from php 8.0 to 8.1.

This appears to have been resolved (and now works as expected) with the changes related to template search in VisualEditor:
https://phabricator.wikimedia.org/T274907
https://phabricator.wikimedia.org/T286990

In T323482#8607853, @Pspviwki wrote:

@lucamauri That is a definitely blocker for me, blocking any upgrade from 1.38, regardless if it is caused by 1.39 or LabeledSectionTransclusion extension. This functionality is used on high number of pages for me and is essential.

I'll just add, this is not just a problem on first save, nor a temporary problem, it occurrs intermittently on subsequent saves, at a rate that can not be predicted. So, a well meaning editor will edit a page, break the cargo table, and not know to purge--we had to splash warning messages all over, to purge if tables not displaying correctly. It is also still broken on every Page Forms query. It is also is always still broken in Visual editor (always displays escaped HTML in live edit, per the above noted configuration). In short, it is persistently broken in multiple configurations.

Not sure if this helps. For me, on further standalone MW 1.39/Cargo 3.3.1 install, the problem occurs in multiple places (source edit on save if no extensions installed, and in VE edit mode--if VE enabled).
On Miraheze which has different cache settings $wgMainCacheType = 'memcached-mem-2'; the problem is primarily on page save, yes--I don't know about editing with VE there, as the extension was disabled on MH and prevented from being re-enabled on most wikis due to multiple issues.

No idea if this makes sense or not, but this issue appears to be occurring between Cargo and the MediaWiki cache, or specifically $wgMainCacheType.

I updated to confirm that this problem still exists on Cargo 3.3.1 with all extensions except Cargo disabled--i.e., I can confirm this problem is not related to the ConfirmEdit extension, it is directly related to Cargo.

I can also confirm the same issue is also occuring on the version of RenameUser packaged with 1.39:

Thanks @Umherirrender, works great.

Turns out that skin.json also needed line 95 changed to a capital P:

No, that fix still doesn't fix it. So, there's something else wrong elsewhere since the renaming.