Just to make this a bit more clear, let's replace o here (and below) with something like <expr> so it is clear that this isn't just using a variable, but for any method call or other expression. If it was always a variable, we wouldn't need o$instanceof_1, that's the purpose that this extra variable serves.

Something like

Sometimes you use the o prefix, others you don't, lets remove it?

Good test - but what if the two variables with the same name have different types, or is that covered and I missed it? This looks like it could get bitten by the "flow scope" that the JEP discussed.

I'm reasonably confident that this is already correct form looking at some of the AST test output, but I don't actually see a test that tries these cases.

One more set of tests I can think of that might break with the X $instanceof_1 decl: a var type, for something that can't be expressed easily, like an anonymous inner class, or a type intersection (like was fixed by ffe6183) since that was also using typeMap.get(...).

var obj = new SomeClass() {
  public String addAnotherField = "hello";
};
if (obj instanceof SomeClass a) {
  //...
}

This could really only matter if there was some other logic going on that would let the type be something else entirely, I'm not thinking about "how this makes sense", but "how this might break the new declaration".

var value = true ? "a" : 'c';
if (obj instanceof CharSequence c) {
  //...
}

This one sort of makes more sense, but still is mostly about "hmm, that code looks like something else that has been able to break before".

I'm not sure if this test belongs here or in the Java17Test, up to you.