Google is rejecting it to ensure incoming messages aren't spam. SHOULD means "you should do this unless you have a really, really good reason not to." Do they have a good reason not to? It doesn't seem so, meaning Viva is in the wrong here.

No, SHOULD is defined in the RFC, not by colloquial usage. Google is on the wrong, regardless of their "safety" intent.

After all, linguistics is full with examples of words that are spelled the same, but have different meaning in different cultures. I'm glad the RFC spelled it out it for everyone.

The RFC says a SHOULD is to be treated like a MUST, but well-justified exceptions are allowed.

RFC speak requires you to think for a while about skipping a SHOULD. It doesn't require strong justification.

No it doesnt lmao. It's quoted all over this thread and clearly is not in any way like a MUST

if Google's choices are protecting users, they can't be in the wrong. That's the reality of a shared communications infrastructure regardless of what the docs say.

When the docs disagree with the reality of threat-actor behavior, reality has to win because reality can't be fooled.

Spam senders don’t have pseudorandom number generators?

They're more likely to put in the least amount of effort or care the least about the reasons how the header is used later on.

Did i miss the part of the RFC that says google must accept every message? Pretty sure the RFC allows email providers to reject any message they feel like.

RFC cannot force a mail server to accept spam. You may argue that requiring message-id is a bad anti-spam policy but it does reduce amount of spam. In my observations around a half or messages without message-id are spam. I would not use personally this as the only reason to reject a message but I understand why someone may choose to do.

The RFC says a SHOULD is to be treated like a MUST, but well-justified exceptions are allowed.

Per RFC2119: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

So, it's fairly explicit that the sender should use message-id unless there's a good reason to not do so. The spec is quiet about the recipients behavior (unless there's another spec that calls it out).

Not a specification but "Be liberal in what you accept?" comes to mind. (which I always personally hated but i'm just one shoveler).

Postel's law was a precept of the Internet of the 80's and 90's, when due to the primitive software engineering practices at that time, implementations couldn't be tested properly. That lead to many cases of poor interoperability, and it's no longer a good idea: for example, when HTML 5 was designed, they decide to put into the spec how to deal with the frequent errors like mismatched closing tags, etc... because all major implementations were "liberal" in what they accepted, but each in a different way.