Aryeh Gregor wrote:
First of all, all auto-generated internal links (in TOCs) will automatically switch to the new format. Second of all, it should be one extra line of code to fix up all manually-created internal links as well, so that the x is automatically added as part of the encoding process. (I didn't find where this needed to be done at a quick glance.) So we're only talking about external links here.
This is a one-time cost and I don't think it's a big problem -- at worst, a few users will end up on the wrong part of the page. It should be pointed out that this will affect *all* section links on non-Latin wikis (since they get encoded to begin with dots and then need to start with a letter), but again, only as a one-time cost, and only external links (links from external sites or links using external link syntax), and it will still get viewers to almost the right place.
A point I haven't seen anyone bring up yet is that, if we're messing with section anchors anyway, this would be a good time to try to make them less likely to collide with other IDs on the page.
For example, now that we've forced all section anchors to start with an ASCII letter, we could go one step further and force them to start with an _uppercase_ ASCII letter. Since most if not all of our other ID attributes start with a lowercase letter, this would conveniently place the two in separate namespaces.
Of course, other disambiguation methods would also be possible, but the uppercase trick strikes me as having minimal impact -- in particular, it just happens that most existing section headings on most of our Latin-alphabet projects (including by far the largest one, en.wikipedia) _already_ begin with a capital letter, and therefore will not be affected. Indeed, this seems to hold even for our biggest project using fully case-sensitive page names, Wiktionary.