Not to bash on libraries or APIs but I think this topic is interesting in terms of discussing to learn what makes an API or library good/bad from a user perspective.
Inspired by this post discussing what makes a good library: http://cbloomrants.blogspot.com/2015/09/library-writing-realizations.html
Old PayPal APIs: while generally not many APIs are required, figuring out what ones to use was horribly painful.
Google Workspace: even though our company was large and had account reps to help, sorting through their horribly written documentation and figuring out the APIs was a shocking nightmare. You couldn't help but compare to this to the earlier days of Stripe: awesome docs, great API design, trivial to get sandbox accounts, responsive and knowledgable free support.
Too of often I think these APIs were written by people who had no good fundamentals on what the complimentary side of development life is like as a consumer of the API. Happy to grant that these people were rockstars at solving other problems... but this was NOT strong point.
Even what should be trivially easy (e.g. did the request succeed or not?) required parsing API-specific responses. And if it failed, good luck trying to know why and whether anything could be reasonable shown to an end-user.
Not sure if every graphics API is the same but it seems like a very "stateful" and "global" API if that makes sense.
For example to adjust the settings of an object you have to first "bind" that object with one API call to "activate it".
Then any subsequent API calls are now modifying the object that is currently bound.
It's been developed in a vacuum, with no feedback from developers. This bullshit could have bankrupted Microsoft, had it not had so much money (to throw away).
side note: WinRT is what Windows 8/8.1 is based on, and quite a lot of it has persisted to this day (Win10) in one form or another.