Future API revision idea ...

So I have been thinking about this (https://github.com/OData/AspNetCoreOData/issues/266) a bit more.
I've been thinking about my interactions with the framework and the code I have to write to deploy OData based API's and I think I could throw out 90% of my code if some stuff was declared slightly differently and a convention based BuildHelper could provide the models ...

Could the ModelBuilding stuff not be computed if we simply added a few more attribs to things, for example ...

// set name could be inferred by replacing "Controller" with nothing or in the case of the base using the name of the generic.
[OData(ModelName = "MyEntities", SetName = "Foo")]
public class FooController : ODataController<Foo>   /// <-- I would make this an abstract base in the framework and implement crud here
{
      // The existing HttpOP(route) might be able to handle this with some smarts but this makes it more explicit
      // or just [Action] for actions attached to an entity by key
      [CollectionAction("DoStuff", Verbs = new [] { HttpGet, HttpPost })]   
      [EnableQuery]
      public IActionResult DoStuff([FromBody] object someData)  => return Ok(BusinessLogic.DoStuff(someData));
}

for "out of the box with no real change type stuff" we could just declare ...

[OData(ModelName = "MyEntities", SetName = "Foo", Type = typeof(Foo))]
[OData(ModelName = "MyEntities", SetName = "Bar", Type = typeof(bar))]
public class GenericController<T> : ODataController<T> {  ... }

I'm sure with a bit more thought this could be fleshed out in to a more fully formed idea that requires no model to be declared at all.
The other thing I thought might be helpful in some situations is to have more direct control over the application of EnableQuery
I noticed that it handles OnActionExecuted internally.
what if we could override that as a controller method but not an action?

This might allow for more interesting "EF style filtering" and the like to be implemented as a customisation directly in the controller.

Then there's the initialisation process ...
So at the moment in addition to having to declare all that model code I then have to construct an EDMModel from it and serve that up for this call ...

services.AddControllers()
    //.AddNewtonsoftJson(opts => opts.SerializerSettings.UpdateFrom(ObjectExtensions.ODataJsonSettings))
    .AddOData(opt =>
    {
        opt.EnableAttributeRouting = true;
        opt.Expand().Count().Filter().Select().OrderBy().SetMaxTop(1000);
        builders.ForEach(b =>
        {
            opt.AddRouteComponents(b.GetType().Name.Replace("ModelBuilder", ""), b.Build().EDMModel);
        });
        //opt.Conventions.Add(new MyConvention())

    });

My thinking if we did all the above (and probably a few more attribs for a complete implementation) we would end up with ...

/// here's the build helper I referred to at the start
services.Addcontrollers().AddOData(opts => opts.FromDefinedControllerInfo());

I can see how I might code this myself and am tempted to implement something like this in my codebase but I wondered if this is something that the OData team over at Microsoft had considered building.
This would result in ...

• Me needing no models
• OData getting all the meta it needs to infer the models
• The framework deciding how to declare things correctly avoiding my woes from #266
• Cleaner code on my end
• Microsoft offering up an easy way to show people how to get started with OData
• More of the MVC mentality applied to OData setup

The down sides ...

• The framework could be perceived to be abstracting more away from us as consumers.
• I have to admit I haven't thought about the full range of complexity this might present
• The shift to this would be quite a big refactor for existing consumers (it's mostly just delete some stuff and put attribs on controllers)

If I gave this a go myself is this something Microsoft might be interested in ?
Thoughts ?