See D19829 for a followup change: getDetail()/setDetail() should be more-private APIs than they are today, and callers elsewhere (like transaction logic) should use methods like getEncoding(), not getDetail('encoding').

Ah, thanks! Yeah, that looks like the same thing. I think the bug title isn't quite correct (runtime is dramatically worse than O(input), but not infinite) and the analysis is slightly misleading (escaping the $ doesn't matter, I think) but the patch looks like it will get the job done (although, offhand, I'm unsure about the ($|(?=")|(?=\$) groups).

• Remove some great but ultimately unnecessary debugging code.

• Return an explicit "available", not null, for available users.

• Mention these flags in the documentation.

I noted the immediate change which exposed this on D19842, for spelunking purposes.

Mostly, there's just relatively little interest from paying customers right now. PHI64, PHI675, PHI723 and PHI985 are all somewhat interested, but they're generally low-priority / "nice-to-have" sorts of requests, or this is a tangential or supplemental approach that might help with some other problem the request focuses on. Since there's limited customer interest, this isn't a very high priority right now.

not a good choice in authentication flows, but just fine when we are talking about these use-cases – and I doubt you would ever allow it to be implement as such

(If you missed it, see also some discussion in D19843.)

This isn't an actionable task. It covers too much ground, describes too many features, and most of it lacks compelling use cases.

I don't expect we'll need to do anything here, mostly just wanted to be able to dig up a list of these if something does come up.

• Better spelling/consistency.
• I agree on the getDetail() inlines, but think getX/setX is probably the better way to make them consistent and that should probably be a separate change and get proper testing. I'll note and revisit this.