These are actually just cosmetic fixes, really, which arise due to the way talklib supports two different kinds of URL.
To summarize what I wrote in the discussion on the news
My patch fixes this by firstly checking to see if, when the journal parameter is given, the user actually exists. If not, it sets a 'nosuchuser' flag and returns. If it does exist, it will check the clusterid for that user to see if they are actually clustered. If so, it proceeds as it did before, otherwise it drops out and lets the other bit of code deal with it.
This creates the illusion that the old-style sitewide itemid is working for that user temporarily. An alternative would be to set a flag saying "usernotclustered" and return, at which point the BML documents can note that. I thought it was nicer to pretend the URL was okay, but this does have the downside that the URLs will break in the future when the given user becomes clustered. I'm thinking that's okay so long as nothing ever links to the slightly iffy URL, just so that users can futz with URLs manually if they want.
The final thing it checks is if the old-style entry actually exists. If it doesn't, it again sets a flag and returns letting the BML page pick it up and print a correct error message.
It's been tested as extensively as I can on my unclustered goathack. I don't know how to configure clustering, and since we've currently got a massive black-box test going on anyway I figured it'd be alright to shove my code up there and see what happens. I've tested everything I can, and everything I've not tested in practice I've tested in theory... that is, I followed the code through myself and saw if what I was doing made sense. That's hardly foolproof, though.