If you think about an expression like e.g. TREAT(alias AS SubType1).subValue1 OPERATOR ... in SQL/relational terms, then the outcome is the same for operators that are NOT null-aware. If you have only SubType2 instances and have a predicate like TREAT(alias AS SubType1).subValue1 = 1 then it evaluates NULL = 1 for every SubType2 instance. Since in SQL using any operator, except for null-aware operators with NULL, results in UNKNOWN the result of that predicate is FALSE. As you can see, the outcome is the same when just considering normal operators. The problem is that you are using the null-aware operator IS NULL which is what the JPA spec doesn't loose a word about.

The JPA spec allows both interpretations with the following from 4.4.9

That is, in the case of a join, the referenced object does not participate in the result, and in the case of a restriction, the associated predicate is false.

but when you consider adding support for other clauses too, I guess that my approach might just have fewer edge cases.
What would your approach do about selecting a treated value like the following?

Consider joining a collection and treating that alias e.g. SELECT a.id, TREAT(b AS SubType1).subValue1 FROM SomeEntity a LEFT JOIN a.collection b.
Say you have the following data

[{
  id: 1,
  collection: [
    { subValue2: 123 },
    { subValue2: 456 }
  ]
}]

The treat I am suggesting returns

[{ id: 1, subValue1: NULL }, { id: 1, subValue1: NULL }]

What is the "local part of the query" in this case?