cc @davidfowl

Sounds reasonable to me

How do we feel about removing the private EndpointFeature wrapper in addition to adding the Endpoint property in the HttpContext?
see EndpointHttpContextExtensions.cs

    public static Endpoint? GetEndpoint(this HttpContext context)
    {
        ArgumentNullException.ThrowIfNull(context);

        return context.Features.Get<IEndpointFeature>()?.Endpoint;
    }    

    public static void SetEndpoint(this HttpContext context, Endpoint? endpoint)
    {
        ArgumentNullException.ThrowIfNull(context);

        var feature = context.Features.Get<IEndpointFeature>();

        if (endpoint != null)
        {
            if (feature == null)
            {
                feature = new EndpointFeature();
                context.Features.Set(feature);
   ...
   }

    private sealed class EndpointFeature : IEndpointFeature
    {
        public Endpoint? Endpoint { get; set; }
    }

Note, there currently seems to be an inconsistent pattern of accessing the endpoint value. The public extension methods GetEndpoint() and SetEndpoint() are used, and some internal code uses context.Features.Set<IEndpointFeature> and context.Features.Get<IEndpointFeature>. This can be cleaned up when public abstract Endpoint? Endpoint { get; set; } is present.

Code relying on the presence of the EndpointFeature in the feature list of the HttpContext would experience bugs. If we want to avoid this, we may need to still maintain the endpoint value in the feature set within the concrete classes implementing HttpContext, or something similar to that effect.

Refactoring the dependency on the Endpoint Feature wrapper is feasible but can break existing code. @JamesNK please let me know if I should proceed with removing the IEndpointFeature wrapper or what you advise, and I will create the PR.