One caveat about this is that it gets dicey if we implement T4280, since user-specified anchors could look like anything and could collide with anything. But we can cross that bridge when we come to it. This is an issue in general anyway, since two users can make comments with the exact same anchor in them.

A minor thing I noticed recently with this is that remarkup linking sometimes won't work if the generated anchor for the file contains . (and possibly other characters). See
https://secure.phabricator.com/D18465#change-cv4o_.vkNhKk
D18465#change-cv4o_.vkNhKk

I currently have no interest with it being fixed, just wanted to mention it somewhere. Should I put it in a separate task?

Yeah, file a new task? I spent 5 minutes looking at this but it isn't entirely trivial. Immediate issues are:

• D123#ab. is ambiguous if we just allow period (part of the hash, or punctuation?).
• If we replace the period we break existing stuff. Probably fine.
• If we replace the period, is DifferentialChangeset->getAnchorName() the only thing we need to replace? I vaguely recall another callsite but it isn't linked here so I'm not sure if it slipped through or I'm misremembering.