I'm a reluctant +1 on this. I want the capability, but find it unfortunate that for now this is probably the right way to do it.
I tried to implement this exact thing with a PropertyWrapper in CodableWrappers and found it to not be possible due to requiring a change to the [CodingKey] path. (BTW if someone knows of a workaround that would be awesome 
).
To be clear, the following is my frustration with the current state of Codable customization not a critique of this specific pitch.
What that, and work building an XML(En/De)coder showed me is that it's really unfortunate custom serialization has been put in the individual en/decoders. This and all the existing customization options in JSON(En/De)coder have nothing to do with JSON, and only exist because it's the only way to do it with the current architecture and tools available.
It also means they're limited to that Type. JSONEncoder and JSONDecoder have ~identical options, but we're forced to set them up separately for both. Beside that, it also means that generic customization isn't available for any other (En/De)coder, which means they have to be added separately, which means they usually aren't, (Not even in Foundation, See: PropertyListDecoder).
All that said, it seems we will need new language tools in order to do it "right" enough to belong in foundation. Since I'm guessing that's still years away and de-nesting serialization is something many would benefit from right now...I'm all for adding it.