A few years back, a number of web development frameworks (e.g. ASP.net) began aiming to target mobile browsers as well as desktop browsers. In order to make this process less labor intensive for web developers they do this by allowing developers to use a generic tag instead of a specific HTML tag (e.g. asp:Textbox instead of input) and then, at run time, looking at HTTP request headers such as User-Agent to determine what sort of markup to actually render to the client. New mappings of headers to markup can be added or tweaked in a core library.
This whole approach was possible because of a brief convergence in the capabilities of desktop web apps and mobile phone web browsers. The former were limping along, the latter had just made a giant stride up from the murk of WAP browsing.
So that whole approach turns out to be a historical artifact. What's next? Maybe Flash Lite, if it would only show up on actual phones in the U.S. I also like the WPF/E concept, although sitting here outside of Redmond, it still looks like a concept both in the implementation and as far as getting it on (non-Windows) phones. In these cases, while there are not quite "magic templates" generating custom markup for each device, it should be possible to produce a single published app which works consistently on all of the participating handsets due to standardized support on the client side.
For Adobe or Microsoft, if it's possible to work the right deal with OEMs and carriers, it should be like shooting fish in a barrel. After all, J2ME is the only real competitor. And J2ME is still more complex than it needs to be, and continues to show no material, credible sign of progress (MIDP 3 included) toward the "write once run anywhere" motto that used to fly on the Java flag.