looks like "OIDC is just OAuth2", so it shouldn't be impossible.

OIDC is a superset of OAuth2 and also removes a bunch of ambiguity which plain OAuth2 had. So a generic OIDC implementation is likely to be less trouble to maintain then a generic OAuth2 implementation.

each OAuth provider has its own quirks[1], which is why we have special code for each provider and no generic implementation.

While with OAuth2 this can indeed be the case, in my experience with OIDC if there is an issue it is usually because one of the two parties (IdP or relying party) is not conform spec. Mostly this comes down to assuming fields are always provided, while in reality they are "optional" in the specification. OSS projects like Dex and Keycloak are in my experience also pretty receptive for bugs reports for these kind of issues. So OIDC issues are usually fixed in the project where the fix belongs instead of making quirky workarounds.