Not at all. In fact, your snippet proves that the correct result is returned.

Of course the correct result is returned.
The "rubbish" part is for the print() function to display that result as 1.12589990684262e+15. The returned result is not 1.12589990684262e+15:

> perl -le "print '1.12589990684262e+15 is not equivalent to 2 ** 50' 
+if 1.12589990684262e+15 != 2 ** 50;"
1.12589990684262e+15 is not equivalent to 2 ** 50
[download]

It's not an approximation.

Well, that depends upon what "it" is actually referring to.
Certainly, the returned value is not an approximation. But the value delivered by the print() function is most definitely an approximation.
In floating point notation, the exact correct presentation is 1.125899906842624e+15.

> perl -le "print '1.125899906842624e+15 is equivalent to 2 ** 50' if 
+1.125899906842624e+15 == 2 ** 50;"
1.125899906842624e+15 is equivalent to 2 ** 50
[download]

I'm sure you're already aware of all of this.
I can see that I could have been clearer in my last post.
It's a PITA having to continually clarify whether one is talking about the the interpolated value (ie the value presented by the print function) or the actual returned value - and I might have got a bit lax about making the distinction.

By contrast, print() always provides accuracy in the values being displayed for IVs - so it's a pity that perl doesn't DWIM by performing integer exponentiation on positive integer operands (and return an IV) whenever integer overflow is not an issue.
Or, alternatively, perl could start interpolating NVs in a sane way. (That's not an unreasonable expectation - python does it; raku does it.)

On perls where IVSIZE and NVSIZE are 8, I'm perpetually astounded that we allow (eg) 1 << 50 and 2 ** 50 to be interpolated to different values.

Cheers,
Rob

PS
In some rare moments of prolonged high-energy I did submit a pre-RFC post to p5p about these issues with NV interpolation.
But I haven't managed to yet summons the energy to deal with the follow up actions requested in response to that post.
As I've mentioned there, my Math::MPFR module provides me with the sane behaviour I seek (coutesty of its nvtoa() function), and it's far easier for me to use that whenever I want sane behaviour, rather than to get too fussed about coming up with an RFC that might then never be acted upon anyway.