• There are some additional places that would also need to be changed: see Escape selectors #13832 (comment)
• There are possibly performance concerns with this approach. Do browsers optimize id attribute selectors like they do #id selectors? Does it take jQuery longer to parse these attribute selectors?
• The Travis build is failing due to some apparent breakage in the unit tests
• New unit tests should be added to specifically test the handling of "exotic" IDs

Does it take jQuery longer to parse these attribute selectors?

Not sure about parsing but Sizzle uses the much faster getElementById when # is matched, see https://github.com/jquery/sizzle/blob/9bf8ecbc8d39e436cdedd23be5f1843e2587c507/src/sizzle.js#L208.

Anyways, as I said in #13832 (comment), support for these "exotic" IDs is planned for v4 so I'd rather not go this route for v3.

I did see that you wanted to wait, but I didn't see any mention of attribute selectors in the proposed patch. If there indeed is a performance penalty, I agree that it is best not to merge these patches.

The patches also introduces some uncertainty in the api since the documentation suggests using # as href value, and then allowing the id to start with a hash.

I will close this as we're unlikely to add support for this in v3.
As I said, support for these IDs is planned for v4 when we'll hopefully have a better infrastructure for common utilities across the plugins, so you just have to use normal IDs until then. Thanks for the work though!

Another weird case is IDs with a colon. For example, Hugo will generate section anchors with IDs like #SOME_TITLE:13f5f3bf.

While this is a valid "href" attribute for an anchor, passing it to jQuery directly will not find the element. However, $("#SOME_TITLE\\:13f5f3bf") will work.