This project https://github.com/Const-me/Vrmac implements unified keyboard+mouse input API over 3 distinct lower-level APIs: Win32 messages, XCB packets, and Linux raw input. Here’s for raw input: https://github.com/Const-me/Vrmac/tree/master/Vrmac/Input/Li... All 3 have unique quirks, yet I would not say they significantly affected the rest of the library.

I think for the USB in that OS, a C API with intentionally very narrow scope would be OK for the job.

The main reason why the real-life code is so complex is that scope being very wide. We have USB 2 and 3, mass storage, two-way audio, cameras and GPUs, hubs and composite devices, numerous wireless protocols on top, OTG, power delivery, power saving features, and more.

A well-written library can effectively expose a simpler hardware device with minimal assumptions

Sure, but even one assumption limits innovation. Even if the innovation is stupid, learning the hard way is useful, so I want at least one student every few years to try that stupid thing and then from personal experience tell the others why it didn't work out.

If we were talking about a serious project there are a lot of best practices that should be rarely (and then only carefully) questioned, but for something intended to be thrown away at the end of the semester challenging best practices is a great way to learn.

That said, PS/2 is a simplifying assumption as well.