Thanks for the new proposal! Out of curiosity I tried to rewrite the example you included for each of the alternatives you presented, and I figured I might as well share them here to save others the trouble.

Original, just as written in the current text of the proposal:

func TestAfterFunc(t *testing.T) {
    synctest.Start()

    ctx, cancel := context.WithCancel(context.Background())
    funcCalled := false
    context.AfterFunc(ctx, func() {
        funcCalled = true
    })

    cancel()
    synctest.Wait()
    if !funcCalled {
        t.Fatalf("AfterFunc function not called after context is canceled")
    }
}

Make bubbles a feature of the testing package:

func TestAfterFunc(t *testing.T) {
    bubble := t.Isolate()

    ctx, cancel := context.WithCancel(context.Background())
    funcCalled := false
    context.AfterFunc(ctx, func() {
        funcCalled = true
    })

    cancel()
    bubble.Wait()
    if !funcCalled {
        t.Fatalf("AfterFunc function not called after context is canceled")
    }
}

Make bubbles a feature of the testing package, but keep the Run function:

func TestAfterFunc(t *testing.T) {
    t.RunIsolated("bubbled", func (t *testing.T, bubble *testing.Bubble) {
        ctx, cancel := context.WithCancel(context.Background())
        funcCalled := false
        context.AfterFunc(ctx, func() {
            funcCalled = true
        })

        cancel()
        bubble.Wait()
        if !funcCalled {
            t.Fatalf("AfterFunc function not called after context is canceled")
        }
    })
}

Same as one of the above, but make the Wait operation a method of testing.TB:

func TestAfterFunc(t *testing.T) {
    // Ignoring the return value here because it doesn't seem to
    // actually be useful. Was the intention to change this to not return a
    // value for this variant?
    t.Isolate()

    ctx, cancel := context.WithCancel(context.Background())
    funcCalled := false
    context.AfterFunc(ctx, func() {
        funcCalled = true
    })

    cancel()
    t.Sync()
    if !funcCalled {
        t.Fatalf("AfterFunc function not called after context is canceled")
    }
}

func TestAfterFunc(t *testing.T) {
    // NOTE: I assume the intention was to remove the bubble arg
    // here because otherwise it would be unused in this example.
    t.RunIsolated(func (t *testing.T) {
        ctx, cancel := context.WithCancel(context.Background())
        funcCalled := false
        context.AfterFunc(ctx, func() {
            funcCalled = true
        })

        cancel()
        t.Sync()
        if !funcCalled {
            t.Fatalf("AfterFunc function not called after context is canceled")
        }
    })
}

Keep the synctest package, but allow it to create a bubble-aware testing.T/B/F:

func TestAfterFunc(t *testing.T) {
    synctest.Run(func (t *testing.T) {
        ctx, cancel := context.WithCancel(context.Background())
        funcCalled := false
        context.AfterFunc(ctx, func() {
            funcCalled = true
        })

        cancel()
        synctest.Wait()
        if !funcCalled {
            t.Fatalf("AfterFunc function not called after context is canceled")
        }
    })
}

I assume the context.Background() in each of these examples could be replaced by t.Context() with essentially-equivalent effect, since the automatic cancellation when the test completes would act as a no-op for this example.

On balance, I think of all of these alternatives I lightly prefer the one you labeled "Make bubbles a feature of the testing package":

• Using a local variable to represent the bubble, rather than package-level functions, communicates clearly to me that this is something I should be manipulating primarily in the test code, and that it is scoped to a particular test without me needing to make any special effort to "clean up" afterwards.

  (I do understand that cleanup is automatic in all of these cases regardless, but for that knowledge I'm relying on context from the proposal discussion so far, whereas this design makes the situation more explicit in the API itself and therefore I expect it to be easier for newcomers to understand.)

• It avoids the extra level of rightward drift that several of the other variants get from having most of the test code written inside a closure.

  (For the t.RunIsolated variant in particular, I also struggled to think of a useful "name" for the subtest. It seems a little odd to force creating a subtest in order to create a "bubble", since those two concepts seem separate.)

• Given that the new API here is relatively small, the cost of adding it to package testing (rather than introducing a new package) seems relatively low, particularly if all of the bubble-manipulation functions are methods of Bubble so that they are grouped together nicely in the docs (which you already said, but I agree!).

This is not a strong opinion, though. I think exactly what you proposed would be okay too.

(For the t.RunIsolated variant in particular, I also struggled to think of a useful "name" for the subtest. It seems a little odd to force creating a subtest in order to create a "bubble", since those two concepts seem separate.)

Yes, this is one of the things I've struggled with on making Run a testing.T method: Either it starts a subtest (but what if you don't want a named subtest?) or it doesn't (but its weird for t.Run to start a subtest and t.RunIsolated not to). Or you have one method that doesn't start a subtest and one that does, but now you've got twice the API surface for not much gain.

On the balance, making the create-a-bubble operation move the current goroutine into a bubble seems to let us have the most orthogonal API.

I like the idea of synctest.Run() (and am a little bit wary of synctest.Start()) because it enforces the invariant that a each goroutine is either inside a bubble or outside of bubbles, and there is no way for a goroutine to jump in/out of a bubble. I find this much easier to reason about, and it feels a bit icky to be able to call a third-party function and end up inside a bubble that affects all of my future execution.

My proposed implementation of T.Isolate intentionally avoids transitioning into a bubble by completely restarting the test in a new goroutine.

// Isolate signals that this test is to be run inside an isolated "bubble".
// The test function will first be run as normal. When this function is called
// for the first time, the test function will exit immediately (via runtime.Goexit()),
// and then the test function will be called again from inside a new bubbled
// goroutine. Once inside the bubbled goroutine, the second call to this function will
// be a no-op.
//
// Since any code placed before the Isolate call will be run twice, this should ideally
// be the first function called within the test.
func (t *T) Isolate()

How an example test would run:

func TestSleep(t *testing.T) {
  fmt.Println("hello")

  t.Isolate()

  a := time.Now()
  time.Sleep(24 * time.Hour)
  b := time.Now()

  if b.Sub(a) != 24 * time.Hour {
    t.Error("sleep not exact")
  }
}

1. The test starts as normal, outside of any bubbles. t is a normal non-bubble-aware T. "hello" is printed.
2. t.Isolated() is run. T.Isolated() sets some internal flag, then calls runtime.Goexit() (or panics with a known object) to return from the test function.
3. The testing framework detects this, sees that the internal flag is set, and run this test again.
4. The test starts a second time, inside a bubble. t is a bubble-aware T. "hello" is printed again.
5. t.Isolated() is run. T.Isolated() sees that the internal flag is set, and simply returns.
6. The test proceeds and finishes quickly in real time.

Curious to your thoughts!

(For the t.RunIsolated variant in particular, I also struggled to think of a useful "name" for the subtest. It seems a little odd to force creating a subtest in order to create a "bubble", since those two concepts seem separate.)

Yes, this is one of the things I've struggled with on making Run a testing.T method: Either it starts a subtest (but what if you don't want a named subtest?) or it doesn't (but its weird for t.Run to start a subtest and t.RunIsolated not to). Or you have one method that doesn't start a subtest and one that does, but now you've got twice the API surface for not much gain.

On the balance, making the create-a-bubble operation move the current goroutine into a bubble seems to let us have the most orthogonal API.

Naming suggestion to avoid confusion -- instead of RunIsolated -- make the method Isolate -- so it's clear it's not a subtest.

so

func TestAfterFunc(t *testing.T) {
    // NOTE: I assume the intention was to remove the bubble arg
    // here because otherwise it would be unused in this example.
    t.Isolate(func (t *testing.T) {
        ctx, cancel := context.WithCancel(context.Background())
        funcCalled := false
        context.AfterFunc(ctx, func() {
            funcCalled = true
        })

        cancel()
        t.Sync()
        if !funcCalled {
            t.Fatalf("AfterFunc function not called after context is canceled")
        }
    })
}

package synctest

// Test is synctest.Run, but it provides the function with a T, B, or F with bubble-aware Context/Cleanup.
func Test[T *testing.T | *testing.B | *testing.F](t T, f func(T))

I'm tempted to impute fork/exec semantics on this, where t is the parent, and Test arranges f(child) more or less as a sub-test of t. I don't think Start() or t.Isolate() ideas are too tricky to use, but I do think this alternative is a little sharper.

My proposed implementation of T.Isolate intentionally avoids transitioning into a bubble by completely restarting the test in a new goroutine.

I've seen this technique (restart the test after calling a function) used to fairly good effect. It's a quite subtle behavior, however, and the edge cases can be surprising and difficult to debug.

For example:

func Test(t *testing.T) {
  time.Sleep(1 * time.Second)
  t.Isolate()
}

I think under the proposed implementation, this sleeps for one real second, restarts the test, sleeps for one virtual second, and then completes. It's even more confusing if the test starts a new goroutine before calling t.Isolate.

The solution to avoid confusion is to not do that: Always call t.Isolate as the very first action in a test. Perhaps we could even have a vet check to enforce this. The API is still sharp-edged, but we could put some safety guards on it.

Another problem is that the test-restarting approach doesn't compose well. t.Parallel marks the current test for parallel execution. Does it matter if t.Parallel is called before or after t.Isolate?

On the balance, I think moving the current goroutine into a bubble has fewer edge cases than restarting tests midway.