In a way...
From what I know, which may not be enough, the network programmers succeed at this because they use virtual machines that have a standardized "machine." What I am also pretty sure of (though not positive) is that - other than Windows Terminal Servers and Citrix-type servers - most of those applications running on servers are, well, server applications. They have no user interface. The user interface part of the application runs on another machine or in a browser somewhere else. In many ways, it is that user interface that is "in charge" even though the server may do most of the work.
In most of the Model-View-Controller designs I have seen it seems that folks keep the View and Controller parts linked pretty tightly together. Only the model is separate. Sometimes, the model is then stored and ran from the server while the view and controller are remote. Even if they run in a browser and the code is fed to that browser from the server, the controller and view software are both still running in the browser together.
Now, perhaps this has already been done, but I like to think "out loud" as it were: What if you put the controller on the "server" too? What if the model and the controller were running in separate virtual machines that had been minimized to only include what that model and that controller needed to run? What if those minimized virtual-servers were designed to be live-migratable from one physical machine to another just like many virtualization managers can do? What if that controller were also in charge of where the user interface appeared? It could send a copy of the user interface to whichever physical machine could connect to it. Perhaps more than one at once. The controller would decide how to construct the UI based on a standardized specification it had been given indicating what "controls" were really needed on any particular device and some style guidelines, also specified in some standardized style language (similar to but more app-centric than CSS). Now, that controller would be in communication with another controller that works to keep track of which devices you are interacting with. You put down your tablet and pick up your phone. The app-controller would notice that you weren't interacting and ask the device-controller to let it know if you start interacting with a different device. The phone, which has been registered with the device-controller but has no inkling of the app already installed on it, indicates to the device controller that you are interacting with it. The device controller tells that app-controller and that app-controller sends an appropriate UI to the phone via an established interface. Initially, the UI is just a dialog that asks if you want to continue interacting via the phone. This could be nothing but a notification on the notification bar. Once you decide to continue interacting, the app-controller could send just enough of the UI to the phone as you need to interact appropriately. Only the UI. The model and controller stay where they are unless ... ... unless you take your show really on the road, where you normally wouldn't have access to that model and controller. Say on a car trip. So, the device detects that you have moved to some location where you may likely move away from the current location of access to the model and controller. Say, you walk out your front door, or start to move around in a manner that indicates you are putting on your coat. The device tells the device-controller which tells the model and app-controller. They tell their respective servers that they may need to move and their servers begin replicating them to a physical server that will be able to continue running those "virtual machines," even if only in an abbreviated manner. For instance, only a subset of the model may be replicated. Then, if you do actually start to move where you would loose access, the virtual machines containing the model and app-controller are live-migrated to the new location, perhaps a server in your car, or running in your laptop (which starts up in a headless server mode to save power), or even in the phone itself, if it has the horsepower. Because the model and app-controller have been ruthlessly minimized, they are much easier to replicate and migrate over wireless connections. Sure, it helps to have some forewarning so the virtualization server can have a head start on the replication process. But, once replicated, they could be live-migrated on very short notice.
I know I have seen videos of how wonderful it would be if you could just put down one device and pick up another and pick up where you left off. But do "they" really have a mechanism in mind to enable this. Or is it just hype and science-fiction? I don't know. Does VMware have a strategy that includes virtualization managers running in cars or in background mode on laptops and phones, with the ability to live-migrate between disparate devices? I don't know.
Too bad I am not a wiz with the code. I am more of a data-standards guy. So maybe I could work on the standards for UI specification and communication between the various controllers and devices.