I don't mind this, but is it super tricky to put the attribute on the return value (because it's kinda more appropriate). Either way it's super nit-picky.

So, that's what I was originally trying to do but I ran into limitations with the Roslyn API when parsing the return method. If you have an action like this:

public IActionResult Foo()
{
  return ValidationProblem();
}

We're able to identify that ValidationProblem was invoked and examine the attributes on the ValidationProblem method pretty easily.

If the ValidationProblem looked something like this:

public IActionResult ValidationProblem()
{
   return new FooResult(); // Where `FooResult` has `DefaultStatusCode` attribute
}

We can't peek into the type returned from ValidationProblem and examine the attributes on it, particularly for the case of ValidationProblem since that method is defined in an assembly separate from the source assembly (and probably other shorthand methods as well).

We should really update these tests to use the new analyzer infrastructure.

Yeah, it might be helpful if we added a list of test areas to #36300 and used that to help us push through on that work.

The precedence is here a little wonky. I would think putting something on the method would be more explicit than putting it on the type. Should we prefer an attribute on the method when specified over the attribute on the type? For instance, the method could do things like configure a non-default status code.

We already prioritize the attribute on the method when specified (e.g. the user is calling MethodThatReturnsIActionResult in the scenario below) over the attribute in the type returned inside MethodThatReturnsIActionResult.

Are you referring to being able to use the DefaultStatusCode attribute on the action method?

public IActionResult MethodThatReturnsIActionResult()
{
   return FooResult();
}

public class FooResult
{
}

public IActionResult GetFoo()
{
  return MethodThatReturnsIActionResult();
}

public IActionResult GetFoo2()
{
  return new FooResult();
}

I guess I was going for this:

[DefaultStatusCode(421)] public override BadActionResult BadResult() => new StatusCodeResult(421);

Looking at the code, it looked we would infer the default as 400 (because that's what BadActionResult is annotated with) rather than 421 even though it's "closer" to the callsite.