That was one of my first thoughts, but I would assume that GAE spam-bot abuse would be smarter than that. If there really was someone doing this kind of stuff, surely they would just block that particular PayPal account (along with banning the GAE user) - AFAIK valid PayPal accounts aren't easy to generate in large quantities. And I can't imagine it's a reaction to a GAE-based DDoS attack, as spotting that kind of pattern ought to be really easy and resorting to blocking URLs wouldn't be necessary.
To be honest, I suspect this to be a bug rather than deliberate, or else you'd have thought that they'd have notified people.
Yeah, it's a difficult problem. In this case, it was a single character that I didn't notice. I'm not even clear on how it got there (or why it wasn't on the second submission URL).
Perhaps the "solution" is to ignore query strings....how many sites use them to distinguish content anymore? Alternately...compare the content of the <head> tag on the linked page? That wouldn't be a perfect solution, but it would probably go a long way.
In any case, I think HN should strip the hash and what follows for purposes of dupe detection, but keep them in the link in case someone actually wants to link to a specific spot in the page.
To answer your question: query strings ("?foo=bar&a=b&c") are widely used. Among other places, HN itself uses them. :) Also, whenever you submit a form with GET.
I honestly couldn't tell you how I got to the page (or what I clicked on once I got there), but it probably involved clicking a number of links.
I had forgotten that HN was using query strings to reference articles...D'oh. By now, I figured that everyone had adopted the URL-mapping approach. Anyway, detecting collisions based on the head tag still seems like a possibility....