Yes, the variable names in the case patterns are treated like variables on the left hand side of an assignment statement. Whatever value they may have had before is irrelevant. A pattern which consists solely of a variable name is a wildcard pattern that matches anything, just as it would be on the left side of an assignment.

Edit: It is possible to use constants or variables in a case pattern, but they have to be dotted names to not be treated like a capture pattern. So this would work for your example:

  class HttpStatus(Enum):
      NOT_FOUND = 404

  match status:
     case HttpStatus.NOT_FOUND:
         return "Not found"

Do you know what would happen with:

    def _id(x): return x

    not_found = 404
    match status:
        case _id(not_found):
            return "Not found"

Yes, and this is incredibly disappointing.

Couldn't we achieve the same functionality with a little less ambiguity using the following syntax?:

    not_found = 404
    match status:
        case not_found:
            return "Not found"
            
        case _ as foo:
            do_something(foo)
            return "Match anything"

it even works for the example in PEP 365

    match json_pet:
        case {"type": "cat", "name": _ as name, "pattern": _ as pattern}:
            return Cat(name, pattern)
        case {"type": "dog", "name": _ as name, "breed": _ as breed}:
            return Dog(name, breed)
        case _:
            raise ValueError("Not a suitable pet")

I'm with everyone on "incredibly disappointing" valuation. But being pragmatic, I had to accept the idea "it can be addressed later" vs continuing this mess. And there was truly mess, e.g. PEP642, which initially tried to addressed just this issue, turned in a hairy monster trying to random-patch pattern matching considerably in rather weird ways.

I don’t understand this. How are we supposed to read the case word? Is there an online interpreter for this so we can play with it?