As for 0xabcdef being a color code, that confusion already exists now, since color codes are, often, not in quotes. So the problem of "confusion" already exists.

So I already excluded octal and someone came up with color codes in hex, which are already oft unquoted, so no increase in confusion w/that example.

So back to the simple case of showing problems where allowing an auto-convert of 0x12 to 18, in a numeric context (where today, it would generate an error).

Part of the problem in finding an example where it would be a problem is you'd have to present buggy code as the example. Code that only runs with a warning and generates '0' as a binary value when used in a numeric context. That's why detractors can't find an example: it would be an example of non-working code.

Now does anyone get the point? The only way someone can accidently use "0x123456" as a binary value today...um...is they can't! They get a warning and the constant "0x123457" evaluates as binary zero. There can be no confusion in current code, because trying to decode a hex constant in a string returns a zero.

As for future code. Maybe allowing hex constants anywhere decimal constants are, as in almost any other language, won't be so confusing to "just perl programmers", since programmers in other languages don't get so easily confused -- why would anyone protest that perl programmers would?