Should this be an enum that also exists on the framework side?

I haven't fully decided on this. On one hand, we could fully define this in an enum, but custom implementers of DynamicFeatureManager may wish to have a custom and/or far more detailed set of states. Maybe show percentage downloaded, etc. An enum on just the framework side for the default implementation could exist for convenience, but I don't want to restrict this particular channel to just these states, as it has potential for more, and could be useful to the more advanced users we are targeting with this feature.

Sure, you can decide. One thing to keep in mind, we'll want to bring this to iOS (at least the asset part) at some point https://developer.apple.com/library/archive/documentation/FileManagement/Conceptual/On_Demand_Resources_Guide/index.html.

Ideally the user should just have to touch the dart facing parts (yaml, asset files, deferred instructions in dart) and never touch anything platform specific or have to read platform specific values.

I'll defer adding enums to a later PR/decision.

Please use standard method codec. I think having json elsewhere is a bit of a mistake but is generally less efficient, doesn't allow bytes transport and we shouldn't encourage the divergence more by using it more.

You wanna cross-reference the dart API that does the same thing on deferred libraries?