Aligning Scrumteams

I agree with your assumption if all teams are working on the same product; however, if they are responsible for different products then why should all teams operate in the same manner? 

Just because the processes that one Scrum team have implemented works for them, doesn't mean that the same processes will work for a different team. 

Each team are supposed to understand Scrum and then implement their own processes based on that understanding, obviously ensuring that they include all items that define Scrum.

To expand on Scott Anthony Keatinge's point, I'd also expect some process commonalities between teams working within a portfolio of closely related products. If you have a portfolio or suite of products with a common market, there may be some aspects, particularly in any deliverable artifacts of the process, that are similar to make it easy to understand for customers using multiple products.

If the assertion was that there were really 20 teams and 10 Scrum Masters working on a single product, I'd want to dig into that. I won't say that there aren't cases where it's appropriate, but I've found that if you have products that support that many teams working on them, you probably have something that can be divided up into multiple products (including considering extracting a common platform). In my experience, the target size for a product would be 3-4, maybe 5, teams. If these teams are well-versed in agility, a single Scrum Master could work with all the teams on a product. Having two Scrum Masters to work closely with the teams working on a product would be fine and much easier to coordinate. When you get to a portfolio level, having a coach at the portfolio level to coordinate across products within the portfolio can be beneficial.

The important thing would be to identify what aspects of the process need to be common or shared and what the teams have the ability to do on their own. Maximize the freedom given to teams to control their own way of working.

In my experience, with 20 teams and 10 ScrumMasters, things can get misaligned. ScrumMasters and teams diverge using their own processes, multiple DoDs, even Backlogs, development processes. The ScrumMasters disagree on common processes and nothing aligns.

That's good. Each team ought to be able to inspect and adapt its own way of working. My own experience is not so positive --usually organizations try to impose some kind of top-down conformity.

I believe that one person is required to ensure the teams align to a single process, this person will "coach" the Scrummasters on what to do.

Why? Why introduce one person who becomes a constraint, and who then seeks to impose constraints upon others?

I'm curious, what is their position in the organisation? Should everything by done via coaching or is there is directing? Is there a practical other solution?

A good agile change agent will reveal rather than resolve. Constraints ought to be challenged. Some are necessary, such as the need to integrate a Done increment, or legal compliance, or indeed the rules of the Scrum Guide. Most however are not.