The relative error must be smaller or equal than 1/2 $MachineEpsilon in all 5 rounding modes of IEEE 754 with all inputs anyway, but in practice no one has that, glibc and Intel do not. That is not what is the problem here, the problem is reproducability.

x8664 Linux and x8664 windows are the same, apart that windows uses LLP64 model (so long is 32 bit only, not 64 as on linux). That may be just a bug in compiler gcc or clang vs msvc on windows. In fact clang ARM has no such bugs and prints the same as in Windows 11, as you confirmed.

So it is bad.

To my knowledge, exp and pow are not considered as "elementary arithmetic operations" in IEEE 754. So strictly speaking, they are not required to be exact to 1/2 ulp. In practice, most implementation are exact up to roughly 1 ulp.

This was fixed in gcc (maybe in 2020? I do not quite remember): https://stackoverflow.com/questions/13774912/gcc-c-pow-accuracy

I would not call the integer-rounding of int(std::pow(100,2)) to 99 a bug. I would rather call fixing this "adding a feature". From a floating point of view, 100 - 0.5 * ulp(100) would be a perfectly correct result for std::pow(100,2). The issue is solely that the integer cast operator rounds always towards zero. This comes quite unexpected for most of us. So probably the gcc developers decided that it might be nice (and lead to less confusion) if every result that can be expressed exactly by floating point numbers would also be represented correctly. But your example 1/(-1.)^1.2 cannot be represented exacly by a floating point number. So one has no choice to rescue to some approximation. And I doubt that there is any standard that mandates, how 1/(-1.)^1.2 has to be evaluated. The only reasonable thing is to expect is that the relative error is in the order of 1 ulp or half an ulp. So I even wonder why you think the Windows version would be the ground truth. Maybe it was only by chance that it returned a "better" result?

Anyways, if you simply want to file a bug report, then why don't you do it where these are supposed to go? Neither Wolfram Community nor Mathematica.StackExchange.com are the right places for that.

Well, I just used infinite precision: [...]

So does Windows always find the "right" solution? Or did it find it here just by chance?

What? Why??

Mathematica.StackExchange.com is purely community-driven. It is not an official channel by Wolfram Research. And, although being an outlet by Wolfram Research, Wolfram Community is also not meant as bug tracker. You should better contact Wolfram Support and issue a bug report there. But I am pretty sure that they will tell you the same as I do.

The relative error is already smaller than 1/2 $MachineEpsilon. Honestly, what do you expect from floating point arithmetic?