So you would turn something like this:

    match command.split():
        case ["north"] | ["go", "north"]:
            current_room = current_room.neighbor("north")
        case ["get", obj] | ["pick", "up", obj] | ["pick", obj, "up"]:
            ... # Code for picking up the given object

In to this:

    if (["north"] | ["go", "north"] := command.split()):
        current_room = current_room.neighbor("north")
    elif (["get", obj] | ["pick", "up", obj] | ["pick", obj, "up"] := command.split()):
        ... # Code for picking up the given object

And the walrus operator would assign to 0-many values as required? It kind of breaks it's current meaning and makes the lines very complex, I don't think this version would be more liked...

Yes. The second version is "pythonic" and follows the principle of least surprise.

The first version is certainly cleaner, but introduces, effectively, a new DSL sublanguage.

The second version also effectively introduces a new DSL sub-language, it just puts a walrus operator at the end of it.

I agree the matching is complex, you only have to see what a portion of the grammar file it takes up: https://docs.python.org/3.10/reference/grammar.html

But embedding the match constructs inside existing Python symbols wouldn't reduce the amount of new grammar it would require.

The walrus operator is not the point; the existing constructs should be expanded, that way things make sense and are composable.

E.g., pattern matching of this sort

    for ["get", obj] | ["pick", "up", obj] | ["pick", obj, "up"] in list_of_get_commads:
        ...

IMO should have "just worked".

But now we have two different and incompatible versions of pattern matching in Python.

That's not an existing construct, it's a LHS assignment language like the match statement but it's embedded inside a for-loop.

Which means you have to implement all the grammar of the current match and it restricts to only works on iterables.

How would you implement this for an object that isn't iterable?

The example is misconceived to begin with? Why are you hard coding an interactive fiction game in Python? You should make an interactive fiction engine, of which there are already a million examples, and then write the script in a language made for IF, not Python.

I took the example from the PEP itself, feel free to list out a different one.