I’d start from some underlying primitives here and build up understanding from there:

• In elixir everything is an expression, which can be evaluated to a value – there are no statements or void return values.
  E.g. x = if 1 < 2, do: :a, else: :b will bind x with :a
• The value returned by a match expression is the value of the right hand side value in the match expression.
  So for ^y = (pattern = y) the pattern = y will evaluate to the value of y
• In the above the binding of pattern is kind of a side effect as it doesn’t affect the return value of the match expression.
  Therefore for the outer match expression ^y = (pattern = y) can be simplified to ^y = y
• Being right associative match expressions can be chained without affecting the above properties even if you leave out explicit parenthesis. Each chained match expression will evaluate to the right most “input”, with all the individual match expressions having the chance to fail matching as well as resulting in variables being bound as side effects of their matching.
  a = %{b: 1} = %{d: d} = %{b: 1, d: 4} and the following function essentially the same.

%{d: d} = %{b: 1, d: 4}
%{b: 1} = %{b: 1, d: 4}
a = %{b: 1, d: 4}

These properties make it essentially irrelevant in which order patterns are placed in a chained set of match expressions, though only the patterns, the right most value needs to stay on the right. Yes technically there is an order – you could move least permissive match patterns more right to match earlier than less permissive ones – but in practise that’s really irrelevant.

Now finally moving to function parameters. Usually these cause confusion because the actually imporant “right most input” doesn’t actually show up when writing a function head.

Having a function shows just a chained set of match patterns.

def my_function(a = %{b: 1} = %{d: d}), do: […]

When calling my_function(%{b: 1, d: 4}) internally you’ll essentially get these patterns evaluated as: a = %{b: 1} = %{d: d} = %{b: 1, d: 4}, adding the provided parameters to the right most side of the chain.

Hence in function heads you can reorder all parts of a chained match expression given the input isn’t present explicitly and it wouldn’t functionally change the function (beyond microoptimizations).

Match is right associative.
So,

%{a: x} = %{b: y} = %{a: "what", b: "happened"}

is really:

%{a: x} = (%{b: y} = %{a: "what", b: "happened"})

Also, Map matched on partial keys, so, %{b: y} = %{a: "what", b: "happened"} is a match, resulting the full map.

I think the article has pretty clear wording, for example if you have:

def hello(%{name: person_name} = person) do
    IO.puts "Hello, " <> person_name
    IO.inspect person
  end

The value person will have the entire map passed as the argument binded to it and person_name will bind the value of the key name. This kind of match also enforces the argument to be a map and contain the name key.

I don’t think you can “give” precedence to the pattern match with ( ). I think they will just be ignored

In your example (%{a: x} = %{b: y}) = %{a: "what", b: "happened"} is a pattern match where the rightmost value is %{a: "what", b: "happened"}, so it has to be known and can’t bind variables, and the left side is (%{a: x} = %{b: y}) which is a pattern that the mentioned value has to satisfy. It means that the value need to satisfy both %{a: x} and %{b: y} and it will check against %{b: y} first before doing %{a: x}. That means that if the match fails on both patterns, the execution will stop and error on the b match first, but in order for match to succeed, all the patterns on the left side need to be matched.

So you are not comparing %{a: x} to %{b: y} - these are patterns for the same input. The only way when two patterns on the left side can interrupt each other is when they bind to the same variable, as there is a rule that value can be bind multiple times in one expression only if it binds to the same value. So %{a: x} = %{b: x} = %{a: "what", b: "happened"} will fail

EDIT:
Ok. No longer so sure enough about this statement to give tips on how it actually works. I simply always perceived match operator as folding from right to left, checking patterns in the process but it might be just my mental model

and it will check against %{b: y} first before doing %{a: x}. That means that if the match fails on both patterns, the execution will stop and error on the b match first, but in order for match to succeed, all the patterns on the left side need to be matched.

Erlang pattern matching is inspired by prolog. In prolog you can have bindings on both sides of match and it will try to solve it like an equation. I think erlang also supports a limited version of this behavior.