* Implementing nTimeLock transaction
* Implementing Sequence
* Implementing mult-sig redemption (via multiple wallets)
* Implementing blockchain pruning
* Implementing standardized export/import formats
* Developing double spend prevention systems
* Developing mechanisms to better protect hotwallets
* Developing 0-confirm guarantees (for truly instant purchases)
* Expanding support for bitcoin libraries (bitcoinj is a nice start but lets see something equally comprehensive for php, python, c#, C++, C, etc)
* Expanding the number of clients (centralization of developer is a risk to a p2p network)
* Developing dedicated backend "clients" (think service/daemon connected to enterprise DBMS or did you think Amazon was going to use bitcoind)
* Developing user friendly clients (I mean really user friendly. Like my Grandmother can split a check w/ friends using Bitcoins friendly).
* Improvement in blockchain download / new node bootstrap process/speed.
* Developing 51% attack detection/mitigation/recovery systems.
* (about 10,000 other things)
"Worrying" (trolling) about not enough discrete units if Bitcoin becomes millions of times more popular in some future decade is just pointless.
Excellent, then I assume the next chain fork will include more decimal points. Or is that going to be put off the next (inevitably failing) chain fork?
Not chain fork, but rather "potential chain fork". BIP16/17 was a potential chain fork that wasn't a real fork, because it was well managed. The process will get easier, not harder, as we practice more and more potential forks along the years, for reasons far more important than decimal points.
All those 1B of users that you mentioned won't be running full clients anyway. Even today there's no reason to run a full client today if you just want to pass some BTC around.
Give up the thread ... please, "including more decimal points" won't happen in the near-medium future.