The theory that stacks are better than registers for an interpreter was pretty conclusively disproven by the Lua 5.0 interpreter. See https://www.lua.org/doc/jucs05.pdf (summary: although decode is slightly more expensive per opcode, you have half as many opcodes to decode on average because you get rid of all the stack manipulation instructions)
... and IIRC this list is no longer sufficient; you need to add to it in order to compile with the current Windows SDK. (Upon closer inspection, it was updated two weeks ago, so maybe it's fine... until the next Windows SDK update.)
I'll admit that this happens less often on Linux, where the system headers are smaller (and everybody uses X11 so there's historic reason to avoid all the short names that were gobbled up by Xlib in the '80s), but I've still run into occasional clashes between different library headers, or between legacy code and updated headers. eg. bool/Bool/BOOL are common collisions among pre-C99 libraries (including libraries that require C99 but don't remove the old names for backwards compatibility reasons), as well as min/MIN/max/MAX which still aren't in standard C as far as I can tell.
The headaches it gives are real, but not large in the grand scheme of things. The lack of defer (or otherwise standardized and cross-platform __attribute__(cleanup) ) is a bigger headache, for example.
"Battery powered coffee grinder" but worse: "battery powered drill, but with Li instead of NiMH" Milwaukee Tool v. Snap On (lots of commentary, here's one example: https://www.youtube.com/watch?v=Y9CLvU5-FRo )
On the software side, AFAIK the infamous "One Click" patent was never held up in court, but companies had to spend significant money defending against lawsuits based on it (and therefore the only possible victory was pyrrhic).
I'm not able to find the methodology for the w3techs report, but I suspect they only count the ultimate root, not any intermediates.
Let's Encrypt's root is not trusted by any browser yet, so they got a cross-signature from IdenTrust. So far, basically everybody using Let's Encrypt chains to the IdenTrust root.
Given that IdenTrust grew from "<0.1%" to 5.6% since the launch of Let's Encrypt, and the shape is roughly the same as https://letsencrypt.org/stats/ , I strongly suspect that the 5.6% market share credited to IdenTrust actually belongs to Let's Encrypt.
As a check, we can divide 2/3 of the total unexpired Let's Encrypt certificates (~2.8M as of last week, 2/3 because standard practise is to renew a 90 day cert after 60 days, so 1/3 are probably overlapping = 1.86M) by the total number of https sites (I had a hard time finding this, but http://arstechnica.com/security/2016/03/more-than-13-million... claims that 5.9M is 17% of https servers, so 34.7M), and we get 5.4%, which is almost the same number as the IdenTrust number above.
That's still nowhere near Comodo, but it's not completely insignificant.
indent(1) is not idempotent, at least not in the configuration I tested, which makes it practically useless as an editor save hook or an SCM pre-commit hook.
Of all the C pretty-printers I tried (about a year ago), clang-format came closest but none were idempotent on the codebase I threw at it.
go fmt is idempotent, which means I use it in an editor save hook. I got used to the convenience, so now I miss an automatic formatter when writing other languages.
Basically, 8 characters or more, but prevent the user from picking a password that appears on any of the leaked password lists. Store in pbkdf2 or better; use argon2id per https://cheatsheetseries.owasp.org/cheatsheets/Password_Stor...
That's it. Simple. No mandatory symbols. No mandatory changes after a period of time. A password strength estimation meter is optional.
If it needs to be more secure, I might require more minimum characters, but no other restrictions.