Comments

Also, if you could throw in a magic word (like DEFAULTSORT does for category sort keys) to make #formatdate use a particular format for users with no preference, that would make it even more useful. Otherwise enwiki people will just complain "It's still no good because IP users will see mismatched dates".

First, a nitpick: Escaping closing braces is unnecessary unless you're within the context of an open brace, so your changes to the prx* lines don't actually do anything... however, if you just want to clean up the code to be easier to read, you should also change the prxISO1 (missed a set of closing braces there.)

More substantially, I'm not so sure about the changes you made to the case statements, getting rid of the checks on the "ISO" bits. Note that there's a transformation there from the 'j' or 'F' bits into their equivalent 'd' or 'm' form, which is no longer taking place in the changed version. I'll checkout a fresh copy of the code and try to come up with some test cases, but you might want to look into it as well.

Good work, by the way! I think this might make a template solution feasible, or at least be a step in that direction.

Ah, thanks Werdna for the explanation on enwiki. For the record, the 'j' and 'F' bits I was referring to are now taken care of before the case statements are even reached. I'll still checkout a fresh copy and run some test cases, if only to shut up the critics on enwiki who are complaining about the lack of transparency in the test/commit process. I expect the code will work fine, though.

Pity IP users and the vanishingly small proportion of registered users who choose a preference will see different displays: that is asking for trouble. Pity about the total failure to deal with all of the other major problems with the blue-wash autoformatting, like date ranges (getting the en dash, spaced or unspaced, right, and not requiring huge amounts of redundancy, such as "January 4 – January 6, 1980". And has it been tested, we all want to know.