Except that the screen and the radio are 80% of power usage, so this doesn't help anything. For what most people do with their laptop/tablet/phone, the little bursts of CPU are effectively "free" — increasingly cheap with each process shrink! — while the IO is as expensive as ever.
To be clear, I meant that, when running your average (i.e. mostly-idle, not-very-graphically-intense, yet smoothly-animated) interactive-UI application, with the CPU+GPU module needing to stream vaguely-realtime updates wirelessly over to the display module, the display module would end up using nearly as much battery to receive and display the updates as the CPU+GPU module would be taking to generate and send them. It would be a negligible cost for the display module to just do the rendering itself.
Playing games or using the CPU+GPU module as a media server is a 1%-of-the-time use-case. If you want this architecture to not need a lot of battery in the display module, it needs to be low-power for the 99%-of-the-time use-case: scrolling a webpage.
(This is basically the classical thin-client / fat-client paradox: thin clients save on power right until you want them to do anything continuously. Then the IO costs outweigh the hypothetical costs of localizing that continuous CPU/GPU activity by pushing it down into a fat client.)
I read that as to say one should do both. Let the client render simple things, do the hard stuff on the portable server.
No offense but it sounds like you simply refuse to look for anything interesting in the concept. Or you forgot to mention it. HN the tech website where we collectively try to shoot everything down. haha
I don't see anything that appeals to me or anyone I know (and I know some very geeky people!) in the concept.
You can certainly add the CPU/GPU module — it's just a NUC with a battery strapped to it, essentially — but if doing so doesn't make the display module lighter-weight and longer-lasting than a smartphone for what people tend to use a smartphone for, then I don't see what I gain by carrying it.
Remember that the conversation here is in the context of an OP about mini-sized phones; everyone in the thread is presuming your point had something to do with the separating-out of compute from other tasks resulting in the "terminals" you mentioned, becoming more like the "iPhone Mini-sized Android Phone" referenced in the OP. You did seem to imply this rhetorically, phrasing your desire as those terminals being "nothing more than" components X/Y/Z — as if this would imply they could be lighter-weight, etc.
But if you concede that even with your Personal-Area-Network (PAN) compute-offload module, the smartphone-sized display module effectively still needs to be a smartphone in order to be a "fat client when that is advantageous", with all that that implies... then you've lost the interest of everyone here, who were all hoping you were proposing some sort of key perspective shift that would allow for smaller, thinner, lighter, longer-lasting smartphones.
---
And to be clear, I do understand why you would want a PAN compute-offload module; that was a concept tossed around quite a bit in futurology circles ~10 years ago. But the zeitgeist has moved on — 5G came along, designed specifically to address the need to carry around such a brick.
In the modern version of this architecture, your PAN's compute-offload either lives in your house/car/etc., or is just some cloud VPS you're renting — either explicitly, or implicitly through amortization of big hardware payments into an implicit subscription (as with e.g. the Apple Intelligence compute cluster.) The rest of your PAN then uses offloads compute by pushing workloads to it through cellular radio; this is practical because the cells for the cellular radio in question are omnipresent enough [and thereby, the handset side of the connection low-wattage enough], and the protocol non-chatty enough, that having such a radio "up" but idle doesn't burn much battery — so every PAN device can afford to do it.
