he tests make it seems like unicode identifiers (and escapes?) now work, but his question implies that it doesn't.

Unicode characters now scan as identifiers in jsdoc, escapes are still not parsed.

Doesn't this change cause us to allow escape sequences in JSDoc identifiers?

No.

That makes sense. It would be nice to have JSDoc support escapes as well, but I think the right way to do that is to make JSDoc use the normal scanner. That's a complete rewrite of the low-level parsing code too, so I'm not sure it's worth it to us.

@sandersn Oh, too late. I already pushed a commit that adds unicode escape support into jsdoc.

I'm pretty sure this deprecates #32631 - can someone double check me?

I don't think so - is jsdoc, at least, we're still going to stop parsing before the hyphen.

I don't think so - is jsdoc, at least, we're still going to stop parsing before the hyphen.

I'm a bit confused by this reply. In JSDoc you shouldn't stop parsing before the hyphen if there's no space. The JSDoc documentation says that it should be able to handle dashes in its member names. For example:

/**
 * @typedef {object} node
 * @property {string} aria-activedescendant - Description.
 */
/** @type {node} */
var node;

That does work in JSDoc from the commandline, but not in VSCode. (See the comments here.)

In VSCode, if you hover the mouse over the "node" on the "@typedef" line, it should show:

type node = {
	aria-activedescendant: string;
}

However, instead you get:

type node = {
	aria: string;
}

with the "-activedescendant" part missing.

If you put quotes around "aria-activedescendant", then you get this instead:

type node = {
	(Missing): string;
}

#32631 was supposed to fix that problem (#14395).