Why does this change?

I assume there are now two copies of a destructor call, one reachable one, and one unreachable one, but it's not clear to me what the unreachable one is.

Good question! I'm also wondering why is it considered as a basic block in the first place.

My immediate hypothesis would that the extractor change only uncovers the problem that was not visible before, and not actually causing the problem here.

I'm also wondering why is it considered as a basic block in the first place.

I think the naming of the BasicBlocks might be a bit awkward in some cases, so I would not get too hung up on the name.

My immediate hypothesis would that the extractor change only uncovers the problem that was not visible before, and not actually causing the problem here.

Would it be possible to reduce this to some minimal example where we see this changing, so we can have a closer look? I agree that it probably uncovers a problem that was already there, but I would like to understand what the problem was.

I'll try to reduce it 🙌

Reduced it manually to the following case:

// semmle-extractor-options: --microsoft
class C {
public:
  ~C();
};

void f() {
  C c;
  __try {
    throw 1;
  }
  __except (1) {}
}

The issue is that we generate 3 destructor calls in this case (and 6 variable accesses, 2 per destructor) and some of these variable accesses (not destructor calls themselves) are marked as unreachable.
Marking these var accesses as children of the surrounding scope fixes the issue, but I'm not sure it's the right solution for all cases.

I think I'll file a separate issue to handle this specific issue.

Thanks for the reduced test case!

and 6 variable accesses, 2 per destructor

Why two per destructor? There's probably an obvious reason, but I'm not too familiar with the code.

Why two per destructor?

I think I was wrong, there is just one var access per destructor (accessing the variable being destructed).

I filed an issue internally.