Stateless clients are basically what @fubuloubu was hinting at (“a formalization of how data storage proofs work”). Nobody has deemed stateless clients as unworkable, afaik. The issues to solve for stateless clients are mostly a question of optimizing the proof sizes, imo.
Issues with deleting hash stubs and resurrection after deletion are around rent mechanisms that propose to delete contract accounts from the state (as opposed to leaving the hash stub there). In the stateless paradigm nobody ever deletes accounts or parts of the trie, so these are not issues. (You could imagine a hybrid version of stateless that also has a deletion mechanism to constrain the size of the trie, with the benefit that everyone’s proof sizes would be slightly reduced in the very long run. But the benefit would be so marginal its probably not worth it.)
The primary critique against stateless is that it leaves unanswered the question of who will generate your proofs, if you don’t want to do it yourself. I make the same critique that rent only answers the question for people who can afford to pay the rent continually, and leaves it unanswered for everyone else (who might deploy contracts that are put to “sleep” and then later must be awakened by providing a bunch of proof data).
Back to the topic of the thread, I don’t think anyone is against trying out experiments somewhere, whether on forks/chains with value or testnets. Its just that it takes a lot of work to run a worthwhile experiment (its called an experiment because its something new which is untried, usually because it hasn’t been built yet). Even if it might be easy to spin up new chains (using a PoA testnet or plasma/polkadot/etc, with value or without), it is hard to spin up new chains with new features. New features must be implemented by someone (not to mention tested for correctness by someone, to prevent experiments from going wrong like The DAO did), and that takes work. Its not that people are shying away from innovation. Its simply that there is too much work to do and not enough hours in a day, imo.
The points on governance strategies and funding core R&D are intertwined because regardless of whether contribution to the R&D fund is mandatory or voluntary, the overarching question is how the funds are governed. A couple of experiments which seem to be happening along these lines include DAOs (like suggested in the State of Ethereum 2.0 report) and the EthSignals ring (or is it called Tennagraph?). Are these efforts minimally sufficient to learn from? Or is there a specific governance experiment the community ought to try in the near term, but which nobody is currently working towards?
Don’t forget that can also try to learn from the governance experiments happening outside of the ethereum ecosystem (“the wise man learns from the mistakes of others”).
On the key point “Eth1x innovation should not slow while we wait for Eth2”, the question is whether Eth1x will be integrated into Eth2 (as some 2.0 researchers hope), or whether Eth1x will persist as a separate chain indefinitely (as some 2.0 researchers expect). There is no canonical roadmap of Eth1x or Eth2 that answers this question.
If Eth1x will be integrated, then (as you said) we as core devs should focus on innovations with benefits that will carry over to Eth2 and/or speed up integration. But if Eth1x persists as a separate chain indefinitely, then we can either innovate on Eth1x, or we slow down our contributions to Eth1x and instead choose to work on speeding up delivery of Eth2. Assuming there are only 24 hours in a day and that we are limited in number, this is a fundamental conflict.