That’s alright 
The way I see it is that we have a market of cryptocurrencies, each having their own pros/cons and each having their own txn. fees. Nano keeps claiming 0 fees, I’ve never used nano. But I have used several on-chain crypto currencies along with many folks in my user group. The transaction fee should have an aspect of being negligible to use the token as a currency. 10,000 zats is 20-50 times more than some of the chains that I use and the communities that I’m in touch with feel this burden. Any fee below 1000 should do as well, but that does not mean we drop to 1 zat. The miners, even though occupied in short term interests (6 months to 2 year horizon for their ASIC investment to pay off) still are better off knowing that the project cares about the incentive model in the long run. The drop to no fee or very low fees bring out several issues, that is why no serious cryptocurrency project wants to play with that.
No. With the proposed default txn. fee of 0.00001 all we need is 312,500 transactions occurring per block to pay the miners 3.125 ZEC per block following the canopy upgrade. Now that is a goal to work towards: to support ~3,500 txns/sec.
I do not see this working synchronously. The light client today only provides info via gRPC calls. And blocks can be found in uneven order of times, so a fee could have changed while the user is navigating through the send transaction screen. There are other aspects for smart contracts that need to be considered. I wouldn’t want to add bloat before the programmable money ideas kicks in. Or maybe I’m just not understanding the simplicity. I would like to see a ZIP with an implementation sample to evaluate this.