Scrum Guide 2020: multiple cohesive Scrum Teams just "should" share the same Product Owner?

I believe you are correct.

The Scrum Guide doesn't make sharing the Product Owner role across teams mandatory. However, consider that the Scrum Guide is primarily focused on how a single team works to deliver a product or service. The Scrum Guide suggests a maximum Scrum Team of 10 individuals, but that's not a hard rule. At some point, though, you will run into problems. If you've grown the team over time, you may see evidence that the team is slowing down. Events, like the Daily Scrum and Sprint Retrospective, may push up against their timeboxes or even not successfully achieve their objectives in the timebox. At this point, the team should consider ways to improve their interactions in order to maximize their value delivery.

If you opt into a scaling framework, different scaling frameworks have different approaches. Both Nexus and LeSS, for example, have a single product owner for multiple Scrum Teams. Nexus is designed to scale up to nine Scrum Teams supporting one product, so one Product Owner would be responsible for the Product Backlog that those nine Scrum Teams work off of. LeSS is built around up to 8 teams sharing a Product Backlog and a single Product Owner. However, beyond 8 teams, LeSS Huge introduces Area Product Owners, who work under a single Product Owner and support up to 8 teams. At the Essential level, the Scaled Agile Framework calls for a Product Owner on each team and a product manager or product management organization at the release train level. I would also point out that, although SAFe uses the term "Product Owner" for the team-level role, the responsibilities are different than that of the Product Owner role as its described in Scrum.

Personally, I believe that there should be a 1:1 relationship between product, Product Backlog, and Product Owner. Not only is this consistent with more of the Scrum-based scaling frameworks, but it definitely aligns with Nexus (which is the scaling framework promoted by Scrum.org). I'd answer the question in this manner in most cases, although it's important to realize that assessments are often against an organization's interpretation of the material and another organization may not agree that the 1:1 relationship is the best approach.

There's written "should share"! I thought it is a "must share".

Perhaps a clue may be found in the preceding sentence : "In general, we have found that smaller teams communicate better and are more productive."

A mandatory practice would not be extrapolated from a generalization.

what is expected from me as an answer in a Scrum assessment for a Scrum.org certificate?

The Scrum framework is minimally prescriptive, and you should remember that in an assessment.

IMHO It is written like that on purpose, as Ian said, Scrum Guide is minimally prescriptive, it is rooted as far as to the very title - Scrum Guide, not Scrum Law. Therefore you can find there much more verbs like: should; could; would; may; etc., rather than must or have/need to.

So we could ask: Is it possible to have multiple cohesive Scrum Teams focused on one product, that don’t share the same product goal, product backlog, and product owner?

I say - yes, I can imagine that, and even accept that it may be effective in some scenarios. Nevertheless, the SG gives us a clue that it should be opposite.

So when we go back to the assessment, statement like that: “Multiple cohesive Scrum Teams, each focused on the same product, must share the same Product Goal, Product Backlog, and Product Owner” is false, as it is too prescriptive. However, statement like that “Multiple cohesive Scrum Teams, each focused on the same product, should share the same Product Goal, Product Backlog, and Product Owner“ is true, as it is only an advice, not obligation.

Does it works having 1 PO and 1 SM for max 9 Scrum teams ? As per Scrum, It is good to have the Scrum Team small enough so they collaborate and focus well. But when the Scrum need to be scaled, PO can be shared among 9 different Scrum teams as per Nexus. Doesn't it cause dependency situation for the teams ? PO can delegate responsibilities to others, still the others have to wait for PO as they may not take decisions on their own. 

Doesn't it cause dependency situation for the teams ?

Potentially. Scaled Professional Scrum is a framework through which self-organizing teams manage and mitigate this risk, while cognizant that scaling is a last resort.

Thanks a lot for your comments. And, yes, it is not the Scrum Law. That, and all the other comments, was valuable to frame it right.