This is like asking "vim or emacs". You'll never change anyone's mind on the matter, but you'll get the same old arguments from ~ten years ago [0] about how this is both "very simple†" and "pointless mental overhead" at the same time.
† (if you follow these rules I memorized to show off how smart I am).
The login provider can emit event log entries which say who logged in and when, and reasons for login failure etc.
Those entries aren't plain text - they are protobufs decoded by a google-provided dll file. If event viewer is open, it won't load that dll, and it will fail to render any event log entries for logins until it is restarted.
A previous debugging hole I fell into once accidentally and barely managed to escape left me with the impression that every event has a "custom" decoder associated; there's no "built-in" event types from the Event Viewer's perspective. There are a handful of very common "custom decoders" that when they break it is an interesting world of madness. In the case of my debugging, one of the decoders installed by the .NET Framework (and used by almost all apps that use the main .NET Event Log libraries) broke and needed repair. It seems like there is a bunch of power in building custom decoders, but I never want to try debugging one again.
That reminds me of a vendor who wraps SAP Business One in their own webservice. This webservice has two business methods.
The first one, ExecuteXML, takes an <XmlBody> representing a regular SAP B1 XML request and passes it on to one of the real SAP services. We have to find our own XSDs for the inner part, because they sure as hell don't have those.
The second one is ExecuteSQL. It lets us run raw SQL against the SAP database. It doesn't have any support for prepared parameters. What it does have is a blacklist to prevent DDL and other funny business, such as semicolons. This blacklist runs on the raw string you send, and doesn't understand any escape characters. To send a string containing a literal semicolon, I had to turn it into CONVERT(VARCHAR(MAX), 0x...).
My thesis was working on top of ConcreteTypeScript, which supports runtime checks https://github.com/ludamad/LocusTypeScript. My contribution was adding the ability to define types inline with code, and check those using tagging. That being said, it's all very experimental.
> Can I possibly even start the discussion at why the hell these things are being named in this way?
This reminds me a lot of Perl with its creative naming for things, e.g. promises giving you a `Vow` object that you can `keep()` or `break()`. Or how you `bless` an associative array into becoming an object of a certain class.
On the one hand, it is good to have precise and specific terms without reaching for a thesaurus or overloading the same term (e.g. the many meanings of `static` in C).
On the other hand, if every framework and language invents its own terms for everything under the sun, that will not help polyglots or newcomers.
(On the third hand, we have foreigners trying to spot a difference between a "promise" and a "vow".)
Promises are my favourite example of this, because just between C++, C#, JavaScript, and Perl, I can find three-and-a-half different taxonomies for the same functionality.
And there's also XKCDB [1].
[0]: http://quotes.burntelectrons.org/browse
[1]: http://www.xkcdb.com/