Either way, pretty much everything in OpenID Connect is optional and/or implementation specific. OIDC providers have to be integrated one by one, adjusting to their slight differences.
I've got to say, I've seen providers without proper discovery, I've seen providers with strange hybrid flows and I'm pretty sure most providers don't implement the request/response signing and encryption (after all, if you want insanity, you'll be more than happy with SAML). But I've never seen a provider who doesn't implement an ID token.
I think everybody would agree that OpenID Connect without an ID token is just plain OAuth 2.
I've had providers with the id_token and access_token being the same value. Other where they were different values. One that didn't support refresh_token at all.
Then a variety of screw ups where the required claims in the JWT tokens are missing or incorrect.
It's wild really. It always takes a bit of work to integrate any OpenID Connect provider. Most libraries only care to handle Google or Facebook login.
From example, the request object in OpenID Connect (that can prevent authorization request parameters from tampering) is only just now coming out as an RFC https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19