if (isAtomic || (postYesDoneLabel == originalDoneLabel && postNoDoneLabel == originalDoneLabel))
```
correctly skips the backtracking section when neither branch backtracks — in that case there is no switch on `resumeAt`, so no stale value can cause harm, regardless of loop status. The stack push/pop at lines 2602–2640 (compiler) / 2594–2620 (emitter) is already inside the `else` block and gated on `isInLoop`. ✅

---

### ✅ (2) `isInLoop` true while both post-labels equal `originalDoneLabel` — harmless dead code

This can happen when the conditional is inside a loop but neither branch introduces backtracking. In that case:
- The `|| isInLoop` causes `resumeAt` assignments to execute (dead stores).
- The gate condition takes the **if**-branch (line 2585), so no backtracking section, no stack push/pop, and no switch on `resumeAt`.
- Since `isInLoop` is only set when `!isAtomic` (lines 2480–2484), and `resumeAt` is only declared when `!isAtomic`, there's no risk of writing to an uninitialized local or undeclared variable.

Net effect: a harmless extra store that never gets read. Same pattern as `EmitBackreferenceConditional`. ✅

---

### ⚠️ (3) Tests are good for resumeAt=0 and resumeAt=1, but miss the resumeAt=2 (pass-through, no no-branch) case

Every new test pattern uses `(?(condition)|no-branch)+` — the yes branch is always empty and a no-branch is always present. This means:
- **resumeAt=0** (yes branch): exercised via `|| isInLoop` because the empty yes branch doesn't change `doneLabel` (`postYesDoneLabel == originalDoneLabel`), so the old condition would have been false. Good.
- **resumeAt=1** (no branch): exercised both ways — some tests have a backtracking no-branch (e.g., `(.)+`), and `(?((?'-1'))|(?'1'a))+` has a non-backtracking no-branch where only `|| isInLoop` triggers the assignment.
- **resumeAt=2** (pass-through, no no-branch): **NOT tested.** This requires a pattern like `(?(condition)yes-branch)+` (no `|`) where the yes branch backtracks, inside a loop. The fix for this case is structurally identical to the other two, but a regression test would harden it. Consider adding e.g.:
  ```
  @"(?((?'-1'))(?'1'.)+)+(?!(?'-1'))"
  ```

---

### ✅ (4) NETFRAMEWORK guard / comment change is correct

The new tests are placed **before** the `#if !NETFRAMEWORK` block, so they run on all target frameworks. This is appropriate — the tests exercise balancing groups via `IsNonBacktracking` exclusion, not a framework-specific API.

The comment simplification from:
```
// these tests currently fail on .NET Framework, and we need to check IsDynamicCodeCompiled but that doesn't exist on .NET Framework
```
to:
```
// these tests currently fail on .NET Framework