[WesolyKubeczek]

Tests trump documentation, though:

      ~ perl -MJSON::XS -E 'my $d = {foo => 42}; say encode_json($d); $d->{foo} eq "bar"; say encode_json($d);'                                                                                                   
    {"foo":42}
    {"foo":"42"}
      ~ perl -MJSON::PP -E 'my $d = {foo => 42}; say encode_json($d); $d->{foo} eq "bar"; say encode_json($d);'
    {"foo":42}
    {"foo":42}
      ~ perl -MCpanel::JSON::XS -E 'my $d = {foo => 42}; say encode_json($d); $d->{foo} eq "bar"; say encode_json($d);'
    {"foo":42}
    {"foo":42}

So it seems either the documentation is now wrong, or the assumptions about "usage" are wrong except for JSON::Xs (on Perl 5.32.1).

However, it "works as documented" when the implicit conversion is the other way around:

      ~ perl -MCpanel::JSON::XS -E 'my $d = {foo => "42"}; say encode_json($d); $d->{foo} == 0; say encode_json($d);'
    {"foo":"42"}
    {"foo":42}

> Every time someone tries to flip that, whether encoding arbitrary data structures to monomorphic values via a polymorphic visitor pattern, the smart-match experiment, or (as I already mentioned in this story's comments) polymorphic operators for data structure dereferencing, these problems occur.

Nothing in the typelessness of the language, though, makes it necessary to flip any internal state of a variable, though, any time its usage context changes. Especially if the state is readable by public API. Even in a typeless language, the "primary" type of the thing, if it's queryable by anything at all, should intuitively be what it's being set to by assignment or other kind of explicit mutation.

[petre]

You are upgrading the number type to string when you are doing the eq operation and from string to number when doing ==.

https://perldoc.perl.org/perlnumber