@kichalla and I have discussed this issue also on http://aspnetwebstack.codeplex.com/discussions/399311. Today, you need to jump a lot of hoops to provide a custom IActionResultConverter implementation because the HttpActionDescriptor has a deep knowladge about the ActionResultConverters (see the virtual ResultConverter property of HttpActionDescriptor).
It would open up lots of flexibilities if custom IActionResultConverter implementations can be injected through the DI as a service or based on rules (just like as it is with HttpParamaterBindings today).
Comments: What type of flexibility are you looking for? I agree that we should make it easier to replace these instances, but I'm curious how you would use the power. Perhaps we could build some of that into the framework.
It would open up lots of flexibilities if custom IActionResultConverter implementations can be injected through the DI as a service or based on rules (just like as it is with HttpParamaterBindings today).
Comments: What type of flexibility are you looking for? I agree that we should make it easier to replace these instances, but I'm curious how you would use the power. Perhaps we could build some of that into the framework.