If it was because the calls [...] were "in the same statement", this wouldn't happen:

Note that I never said "in the same statement". That surely came from something specific from the C spec. It can be somewhat and roughly applied to Perl in a lot of ways, but in a lot of ways it does not apply.

A lot of people reach for that because it was one of the better known and clearer expressions of the more general concept of "it is foolish to rely upon subtle quirks in a specific implementation" and because many of the examples of this in perl (like print ++$x,'.',$x++) look very much like things that are clearly declared "undefined" in standard C.

Some people push pretty strongly for this mis-application of that part of the C standard to Perl. Some of that is surely motivated by a desire to push back against the naive but powerful urge to declare "same $code acts different" as unambiguously implying "that is a bug" (whether "different" means in different builds of Perl or in different looping constructs or whatever). Heck, you just nearly jumped to the "if an optimization can change anything, than the optimization is buggy" conclusion yourself.

But it will always be possible to do particularly stupid things in Perl code such that the outcome of said thing will be subject to (that is, will be changed by) subtle decisions deep in some obscure part of the Perl interpreter.

But it is also quite easy to avoid doing such stupid things. But that requires that one acknowledge that some things are stupid because they are particularly risky to being impacted by unintended side effects of optimizations, bug fixes, and feature enhancements.

This was made quite explicit, authoritative, and precise in the C standard, so people often reach for it, even though it is an imperfect fit here at best.

If your code breaks when the Perl expression $x.$y is noticed to be inefficient because it does "stringify $x (into a copy), stringify $y (into a copy), concat the two (into a third copy)", then I'm pretty sure you've done something stupid in your Perl code.

But the exact details of how $x.$y gets accomplished might change because it was found that certain cases produce less than desirable results. So if some subtle detail has unfortunate side effects on non-stupid Perl code, then the maintainers of the Perl interpreter certainly might improve those results at the expense of possibly causing code that stupidly relied on those unfortunate results being broken by the change.

Unfortunately, sometimes subtle happens. But I believe that is inevitable.