Similarly, any web site or app that can’t correctly handle a space character at the end of the password should never be trusted with anything of consequence.
To answer the actual question: I don't know because I left my PIN at 4 digits, despite knowing I could use more, precisely because I didn't think it would really make my life any more secure.
The concern is that a 4-digit max PIN length is certainly implemented by someone who couldn't be bothered to read the spec for secure credit card transaction handling.
It's the equivalent of the "No brown M&Ms" clause or "Canary in the coal mine" test.
Nobody actually cares about the M&M color or some dumb bird.
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.
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.
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).
> 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.
Conversely, it seems very possible to support 6 digit PINs and yet still make a ton of horrible implementation mistakes, security and otherwise.
Some of the APIs allow the machine to say "I can accept a PIN up to 12 digits".
However, I don't know if anyone 1) actually delivered on it and 2) how you'd know in advance just poking random devices in stores.
I'm from a country that has 6-digit PINs on most cards, and I've traveled to e.g. the United States where people are surprised that credit card PINs can be more than 4 digits, but in my experience, terminals accept them just fine. It seems like they are designed to suggest a PIN is only 4 digits but they will happily accept more. So while you're entering your PIN, the display looks something like:
[....]
[*...]
[**..]
[***.]
[****]
[*****]
[******]
And from there, with variable lengths ranging from L to H, S(L, H) = 5/4 * 9 ^(L-1) * (9^(U-L+1) - 1)
So if the bank allows combinations from 4 - 6 digits, there would be a total of 663390 combinations to choose from.
Now, of course, the bank may decide to go from decimal to hexadecimal in the future - or maybe, there systems allow only duodecimal. In any case, the formula can be generalized further to account for all number systems - with B being the base of the system:
S(L, H, B) = (B/(B-2)) * (B-1) ^(L-1) * ((B-1)^(U-L+1) - 1)
This is only defined for B > 2 - in binary system, there's only ever two combinations which fit the constraint
"1111" would just leave a fingerprint on a single key, for example, and only one possible PIN (or maybe 3, if the bank/card allows 6 digit PINs).
Takes me back to when my password was leaked: