The pattern goes like this:
1. For each Form that needs to be customized we have a dedicated Visual WebPart (or a regular WebPart, if you want to target sandboxed solutions)
2. This dedicated web part is injected into the form when our web scoped feature is activated
3. Dedicated web part can contain numerous web parts or web controls or script/style references inside of it. They can be like modules, that bring new functionality in. For example, in one list inside of the dedicated web part we have references to A) web control that transforms form so that it has tabs B) web control that sets some values based on URL parameters C) Some references to script and style files
As for compatibility with future versions – this solution will stay compatible with future versions of SharePoint (from architecture point of view) as long as New/Edit/Display form will remain as web parts and as long as SPLimitedWebPartManager class exists and it’s public method signatures are not changed. To my knowledge at least in upcoming version of SharePoint 2013 none of this is changing.
One more strong point of this approach is revealed in team environments where source control is set to Exclusive Checkouts (two or more users can’t concurrently check out the same file). In an environment like this described approach ensures that people can work with different customizations of the same list, because those customizations will be distributed through different files.
I’d like to hear out how you are handling things like this!
Cheers and happy developing!