They do use some B:: trickery, but it's minimal. And the fact is "has it ever been used as xyz before?" is a terrible heuristic. Unfortunately, it's just about the only heuristic available. I love Perl's malleability, but this is one area where it hurts us.

Internally Perl can store a value that looks to us like a number as an IV/NV (integer/numeric value), or a PV (pointer to a string), or frequently both. This rarely matters to the end user, because numeric operations will autovivify a numeric component, string operations will autovivify a string component, and there's very little ambiguity involved. '==' is always for numeric comparisons. 'eq' is always for string comparisons, and so on. It's generally not necessary for the end user to care about internal representation.

This all changes for JSON, because JSON does care whether an entity is a number or a string. There's no JSON generic "scalar" as we have in Perl. This is essentially a type mismatch between Perl's "scalars" and JSON's representation of data. People writing and maintaining JSON modules seem to continually struggle with providing a solution that will present the least amount of surprise to end users. At what point should a scalar be mapped to a string for serialization? At what point should it be mapped to a numeric value? It's not an easy question to answer, and that's why you've seen the solution evolve.

Smartmatch is another example of where the implementation detail necessarily leaks out of the internals to the user. What should "scalar ~~ string" do? What should "scalar ~~ num" do? Should all such matches occur in string context, as though the user had simply used eq? If so, why isn't the user just using eq in the first place? Why should ~~ "smartly" coerce string context to act like eq, but not smartly handle numeric context? (one reason is the JSON problem.)

The fact that the proposal treats all scalar to scalar comparisons as eq is an example of the whole smartmatch shortcoming. It's supposed to be smart, after all. But as soon as we start trying to make it smart, we end up with a zillion special case rules, and users have to consult a manual every time they try to use it; it's too smart. So we dumb it down to a few simple rules, and then the rules make using it dumb, since we may as well have just used the proper operator in the first place.

Perl's operators are type specific in a type-free system. The operators are our type system. There is no meta-information inherent in our scalars to tell us they're ints, strings, or floats, because that distinction is totally dynamic, and totally up to the programmer at any given stage in the program's execution. It's the programmer's decision to use '==' or 'eq', for example. If we wanted Perl to try to guess, Perl would have overloaded '+' for concatenation. Languages that go down that road end up with "==" and "===" to provide imprecise hints, and it usually ends in naive misuse and bugs (I would guess that 50% of the PHP code in the wild misuses == and ===).

Because our operators are how we impose typing on our typeless variables, it becomes highly problematic when we try to invent operators that guess at our meaning in the absence of reliable meta-data. Smartmatch is fine in a language where containers have types. It's madness in a language where operators have types and containers don't.