When nodes perform the initial block download and verification, they start at that genesis block and work towards the chain tip, which is the most recent block.
Got you. For a full verification, this is likely the most efficient way, and also how my own implementation works. After that, new blocks are verified up towards the root until a previously verified branch is reached.... pruned nodes can be vulnerable in the scenario of a chain split ...
Instinctively, I would say that chain splits present no prune-specific vulnerabilities; even in the extreme case that the split is so far towards the root that it can't be reached from a pruned node's partial branches, there's no risk of false verification. In any case, chain splits are so rare and contentious that it would be prudent to revalidate from scratch after each one, pruned node or not.... as blocks become exponentially larger, then chain splits tend to become both become more frequent and longer ...
Perhaps you mean local chain reorganisations, not actual forks? A node may indeed discover a new, longer chain, orphaning previous blocks, but I don't see how this is prune-specific (given reasonable pruning parameters).... You still need a full node if you are going to run a wallet ...
I'm sure you don't really mean this 
... or indeed view any transactions prior to your most recent block. Having only a handful of full nodes responsible for fetching data on all but the most recent UTXOs is a big risk.
Yes, I agree on both. My hopeful guess is that a large enough share of transaction needs could be fulfilled by cheap, pruned nodes (with all blocks from, say, the last 6 months), and that the rest of the data might be stored (locally, hence trusted, or non-locally if partner trust can be established) in a cheap, slow, non-transactional manner.