FWIW, Apple has a history of introducing new models/major upgrades when several key technologies reach inflection points. I have also speculated that they are waiting for Kaby Lake as it appears to offer a more direct link from TB3 to the CPU,
History is right. Hooking the TB controller to the CPU has already been done ...
3 years ago.
http://www.anandtech.com/show/7603/mac-pro-review-late-2013/8
The TBv3 controllers are x4 PCI-e v3. You can take two of them snd directly couple them directly to a Xeon E5 v4 (available now) without the need for above diagram's PEX as a PCI-e v3-to-v2 bandwidth distributor anymore. Removing the PEX switch is available right now. There is nothing new coming with Kaby Lake on this front in the Xeon E5 class space. There is no magic pixie dust coming in two years that will improve that in the Xeon E5 1600 series (or whatever Intel names the equivalent in two years).
What looks like what may come with Skylake-W (the next workstation version likely coming Q2-Q3 next year) is more PCI-e lanes coming out of the CPU package. That would mean you could hook up three, as opposed to two, TB v3 controllers. It is a matter of how many not whether can roll out a product with TBv3 in it. 4 TBv3 ports is reasonable. Apple can throw 2 HDMI 2.0 ports on the back if want six display capable connectors on the back. [ It is extremely doubtful that there are very many folks running with 6 actual TB devices directly hooked to the back of the deployed MP 2013 models. Six was necessary because folks do tend to have a number of displays to hook up ( 3-4 screens probably isn't MPro normal but also probably not extremely rare either). HDMI (or DisplayPort ) would work just fine in that role. ]
which I would expect to be a better topology for eGPU support.
eGPU supports is primarily a problem of OS graphics driver stack support; not wires.
"... While Thunderbolt has in theory always been able of supporting external graphics (it’s just a PCIe bus), the biggest hold-up has always been handling what to do about GPU hot-plugging and the so-called “surprise removal” scenario. Intel tells us that they have since solved that problem, and are now able to move forward with external graphics. ... "
http://www.anandtech.com/show/9331/intel-announces-thunderbolt-3
I think the implication of Intel (and only Intel ) solving this problem isn't quite accurate. I think Intel now has a standard general approach to this which they have a specification for and a testing suite which the major OS vendors have more-or-less signed off on. (i.e., the OS vendors say "Yeah, we can probably do that and are willingly to add that at some point." )
It is largely a software problem. ( their are probably some minor firmware, EFI additions and GPIO handling issues) but the hardware wise. But the "unplug" is not an electrical (hardware) thing... it is what to do when event gets signaled. TB could always tell you something got unplugged. What happens after that is the primary problematical issue.
Apple's graphics stack being months ( sometimes years ) behind what is in the Windows graphics stack... not really new there either. And certainly nothing attached to specific hardware capabilities of Kaby Lake.
Does that suggest we are still a year or more away from a 7,1 MP? Perhaps. Will there be any pro users left on the platform in 2018? A few diehards, sure - but enough to make it commercially successful...
Many on these forums have noted the fundamental problem of creating a 450 watt envelope that can support "pro" use cases. Process shrink might eventually make that easy peasy -
Process shrinks aren't going to make that "easy peasy". This has echos of the same lame excuse trotted out back when Apple skipped the Xeon E5 v3 ( Haswell). "Oh the process shrink of Broadwell (v4) are going to solve the problem and then Apple will move on v4".
The TDP of the Xeon E5 1600 has been relatively flat since the beginning and will likely continue into the future. [ Power regulation moved on package with v3-v4, but that is a ballon squeeze of moving something off the board and into the package. Overall system TDP didn't go up] The TDP power budget is used to roll out more cores at higher clocks with each process shrink.
If Apple cut the top end core count to 4 cores then they could make a substantive shift in TDP. That is not process shrink driven and it really doesn't widen the customer market much.
So the 6,1 form factor is too limiting and Apple seems highly unlikely to go back to big towers.
The form factor and exactly the same current dimensions are two different things. Apple could grow the form factor an inch or so and get to a better solution. The 2013 design is by no means the perfect optimal configuration. There is no reason why the footprint of the Mac Pro has to be smaller than the Mac Mini. Honestly, that is kind of silly. 7.6" x 10.9" would still be substantially smaller than it old form factor. There would be no horror in having a footprint 0.2" larger than the mini. It is still the same new form factor.
The 6.6 and 9.9 of the current Mac Pro smacks more of some weirdo numerology fixation (multiples of 3) and/or attempt to mimic the monolith from '2001 A Space Odyssey' than any sound engineering design.
(Make the Mac Pro 1/3 its former size so the dimensions should be multiples of 3..... that's a conceptual blockbuster exercise, but then need to get down to the realities of what is really required. If one and only one fan .... it is too small. )
In my dream world, Apple would stick with the cylindrical shape and central cooling - but make it taller (in part to accommodate full length PCIe cards internally) with better cooling and a 650w PSU.
Full length cards aren't the core problem. Nor are they particularly necessary (with current tech.). The cards are custom so there no need to comply exactly with legacy slot dimensions.
The bigger problem is that there probably needs to be more cards, not longer ones. If the main and I/O board design iteration is going to be 2-3 years long then they need more cards spread over that interval.
(IHMO it is obviously that they also have a headcount/resource cap here too many cards in parallel is probably isn't going to happen but could keep iterating instead of going into rip-van-winkle mode and pragmatically deallocating for periods of time. )