On 1.1.9, the alert shows all the backslashes in NAMEFILTER. On 1.2.0, the backslashes are all removed. This explains why the WebCreateNewTopic dialog is not working on 1.2.

This can be fixed on 1.2, by modifying core to double all the backslashes in the NAMEFILTER before it is added to the script tag. I've tried switching jquery to 1.8.3 on Foswiki 1.2, but it still fails.

Michael, fixing this in FOSWIKI.pm is difficult because the NAMEFILTER field is rendered late by the %ENCODE% macro. The fix I came up with added a new encode type of 'regex' and uses that type for the NAMEFILTER field. Unfortunately that's not backwards compatible to 1.1.x, so I can't check it in. The real fix would be to not lose the escapes in the first place.

(1) What do we need NAMEFILTER for ... I mean really ... in javascript land?

(2) To prevent jquery.extend() to mistreat the regex string we could add a RegExp constructor which will create an appropriate Object before jquery.extend() sees the string. I still doubt that jquery.extend() does remove any escapes.
This would rather be done by string interpolation of javascript. I will check that.

1) - well we need it partly because it works in 1.1.9 I looked at the jquery WikiWord, but it appears to be very restrictive on what's valid.

NAMEFILTER derived from {NameFilter} allows the javascript code to use identical rules to the Perl code that validates topic names. So if a user enter "my@$foo barTopic", they will get MyFooBarTopic as the topic name. Illegal characters are filtered out and core will be happy with it.

I'll play around with log vs. alert, but it's really quite mystifying, as I showed above, the alert in the same script tag as the extend gives different results on 1.1.9 and 1.2.0 with identical input. ..., even when I drop 1.2.0 back to jquery 1.8.3. I'm rather baffled.

The problem with your above code is the script tag is generated. So it's not straight forward to change the encoding: