@ahejlsberg As mentioned in-person, I've also added the instantiation to the indexed access branch as discussed because it aught to be required, but there's a soundness issue which prevents the error from occurring in the test without the change:

function swap<
    T,
    TContainer extends { member: T }
>(a: T, b: TContainer): TContainer {
    const tmp = b.member;    
    b.member = a; // This is allowed because we check:
    // T -> TContainer["member"]
    // T -> T
    // Assignment of T to TContainer["member"] erroneously permitted
    // because TContainer["member"] is simplified to a constraint of T
    // The constraint _should_ be "some (unknown) P which extends T"
    // In fact, if you annotate an extra dummy generic that is just that,
    // you'd see the assignment prevented.
    a = tmp;
    return b;
}

const obj = { member: { x: "", y: "" } };
swap({ x: "" }, obj).member.y; // Surprise! It doesn't exist!

This hole prevents the same issue from appearing verbatim with indexed accesses; but because I suspect it could matter in the future I've included the fix anyway.

I think #8474 is actually all about this hole. We could probably fix it nowadays, too (fix element access constraints/assignability with marker type variables, make initialized properties become invariant positions), but it'd likely be a bit breaky.

In any case, I think the equivalent fix for indexed accesses is warranted, since diverging behavior between type variable kinds is undesirable, at least.

@mhegazy asked for the perf data for this PR to ensure there's no perf regressions, so here's a 10 iteration comparison from my machine:

I don't see much of a difference, so I don't think this'll cause a blanket perf regression.

LGTM, @ahejlsberg any comments?

@ahejlsberg We had a new report of the same bug with a much simpler test case: #24151

I've added it here and synced the branch - we really should accept this.