//See Binder.CheckValueKind

I am not sure if the reference to Binder.CheckValueKind is helpful. The new helper is used after initial binding, so I doubt we are going to call Binder.CheckValueKind after that. I also glanced at the Binder.CheckValueKind method and nothing stood out to me as an obvious explanation of why what we are doing here is important.

Do we have a test that is going to fail when this if statement is removed?

Do we have a test that is going to fail when this if statement is removed?

Can a throw expression be used in a ref conditional operator?

I do not think we should have a default case like this. Consider using a switch expression without "default" instead. If it is not exhaustive because a named enum value is not handled, the switch expression is going to produce a warning like

warning CS8509: The switch expression does not handle all possible values of its input type (it is not exhaustive). For example, the pattern 'RefKind.In' is not covered.

Otherwise, it is going to produce a warning like following:

warning CS8524: The switch expression does not handle some values of its input type (it is not exhaustive) involving an unnamed enum value. For example, the pattern '(RefKind)6' is not covered.

We should suppress CS8524 with pragma

In some cases RefKindExtensions.StrictIn is actually handled differently by comparison to RefKind.RefReadOnly. I think we should return RefKindExtensions.StrictIn for it and, in case of an ambiguity between RefKindExtensions.StrictIn and RefKind.RefReadOnly across branches, we should prefer RefKindExtensions.StrictIn

Probably always using RefKindExtensions.StrictIn instead of RefKind.RefReadOnly is a better alternative.

I suggest to move this helper to SpillSequenceSpiller.cs right after VisitConditionalOperator, it doesn't have to be an extension method.

Please add a WorkItem attribute.

It looks like this test is failing in CI because Unsafe type isn't available in TargetFramework.NetLatest when the test is executed on Desktop framework. Consider using TargetFramework.NetCoreApp instead and conditionally supplying expected output:

                expectedOutput: !ExecutionConditionUtil.IsMonoOrCoreClr ? null : """
                5
                1
                5
                """);

It looks like this change introduces a compiler crash for a scenario that worked fine before:

        [Fact]
        public void Test1()
        {
            var src1 = @"
using System.Threading.Tasks;

class C
{
    int F;

    static async Task Test(bool b)
    {
        Test(b ? ref (await GetC()).F : ref (await GetC()).F, await GetC());
    }

    static void Test(int x, C y) {}

    static async Task<C> GetC()
    {
        await Task.Yield();
        return new C();
    }
}
";
            var comp1 = CreateCompilation(src1, options: TestOptions.ReleaseDll);
            comp1.VerifyEmitDiagnostics();
        }

This scenario also crashes compiler:

        [Fact]
        public void Test2()
        {
            var src1 = @"
using System.Threading.Tasks;

class C
{
    int F;

    static async Task Test(bool b)
    {
        Test(ref b ? ref (await GetC()).F : ref (await GetC()).F, await GetC());
    }

    static void Test(ref int x, C y) {}

    static async Task<C> GetC()
    {
        await Task.Yield();
        return new C();
    }
}
";
            var comp1 = CreateCompilation(src1, options: TestOptions.ReleaseDll);
            comp1.VerifyEmitDiagnostics();
        }

I suggest trying an alternative rewrite here, a rewrite that doesn't introduce ref locals. Instead of creating a local for result, creating a local for condition might work:

<condition side-effects>
bool conditionValue = condition;
if (conditionValue)
{
     <consequence side-effects>
} 
else
{
     <alternative side-effects>
}   

return conditionValue ? [ref] consequence : [ref] alternative;