"Must support 6-digit PINs" is not part of "the spec for secure credit card transaction handling" – which is also not a (or at least one) thing: There are dozens of card networks, and many of them have tons of regional variations.
In some markets, issuers only allow 4 digit PINs, and customers don't expect to have to press an "enter" key when they're done entering their 4 digit PIN – so the reasonable implementation is to allow only 4 digit PINs, or you'll be left with people staring at the ATM/POS terminal, waiting for something to happen.
Making an ATM that can accept cards from multiple issuers (which is the norm these days) and allowing only 4 digits is the same category of error as requiring that the first character of someone's last name start with a capital letter, or to block symbol characters in names.
I agree: An annoying/avoidable implementation shortcoming, but arguably relatively orthogonal to security.
> there are over a dozen different PIN block standards
You almost certainly don't need to support all of these inside the PIN pad or even ATM/POS. If necessary, translation can happen in other parts of the system.
People tend to very very quickly their mind on that one once they get a few right-to-left control characters that flip over the text layout of the entire program.
Are you arguing to just allow any byte in names (which are ultimately user-defined input data), including 0x00, Unicode byte order markers etc., in a thread about a perceived correlation between developers' lack of i18n awareness and security bugs no less?
The reality is that there is often a tradeoff between keeping your test and edge cases simple via constraining allowable inputs and internationalization.
So I think you've got it exactly the wrong way around: These limitations might have happened precisely because somebody wanted to do the right thing from a safety/security perspective by doing overly strict input validation, at the expense of internationalization/compatibility.
Not saying that that's a good tradeoff in every case, but I really don't think you can draw any conclusions about a system's security by looking at whether it arbitrarily disallows some inputs (or if anything, maybe the opposite).
In some markets, issuers only allow 4 digit PINs, and customers don't expect to have to press an "enter" key when they're done entering their 4 digit PIN – so the reasonable implementation is to allow only 4 digit PINs, or you'll be left with people staring at the ATM/POS terminal, waiting for something to happen.