Possible now because the network is small and tight knit and the developers can "Stop the World" whenever it's necessary to make major changes to the protocol. If/When BTC is as big as Visa, even minor tweaks may be completely impossible without breaking the clients for half the users on the network.
Developers can't "stop the world" in any context, and tweaks can be made to the running network anyway, at least as long as users are willing to upgrade. The network is particularly fault tolerant.
Like they did with the overflow bug? It may be true they can't now, but it could be necessary, and/or it will take a very long time to get everyone to upgrade. Assuming it doesn't get broken because people "upgrade" themselves to game the system.
In particular, I'm not sure how BTC values are stored, except that Satoshi did a lot of stupid and unnecessary things.
You don't know how the system works, but in the same sentence claim that Satoshi did a lot of stupid things? Are you trolling?
When I say "stupid and unnecessary things", I mean the 2GB blockchain that's been generated in only three years and with provably
less than 5-10 tx per minute! At VISA levels that's totally unsustainable. 90% of all "usages" of scripts and contracts are totally economically useless and will probably never be used by anyone for anything, whereas per file size scripts take up the vast majority of unspent txOuts that need to be tracked. The only thing BTC really is is a giant, overglorified balance ledger sheet, that needs only to track unspent account balances per account in order to be accurate. Instead it tracks unspent txOuts individually, which then all must be put into txIns individually in order to be spent, yet again multiplying the size requirement of the blockchain.
If the blockchain had been engineered to efficiently fill its primary purpose- simple yet secure monetary exchange, rather than a bunch of useless contracts by default, then the blockchain could be < 50MB rather than > 2GB. I consider it a product of Satoshi's economic ignorance, although beyond that I can't read his mind so I don't know what else he was thinking when he designed it to be such a complicated mess. The abstraction between public key and address hash is also extra without actually providing much benefit (unless you want to keep your SHA256 pubkey from being stolen by quantum computers.. which would make bitcoin useless in about 50 different other ways anyway).
Even if shifting the currency to the left by one decimal doesn't break backwards compatibility with clients, it would at the very least cause a great deal of confusion. Moreover, it's something that won't even be remotely relevant until decades from now, when the market cap of BTC is either zero or unpredictably large.
Point one isn't true, but only because a decimal shift isn't how it would be done. The values are stored in a 64 bit integer variable, but only about 54 bits are in use, so the leading bits can be taken as a 'marker' to tag values using an extended standard.
Point two is certainly true.
Not counting coin losses, BTC is only capable of holding dollar influx equal to $21Tn before it is no longer divisible by units smaller than $.01 without absolutely increasing the division.
Where did you come up with that BS number?
21,000,000,000,000.00
The number of BTC that will ever be produced (est) with 1 satoshi = 1 cent per decimal places, and what you get is 21Tn, or about twice the M2 money supply of the United States, only divisible down to 1 cent.
A uint64 could potentially hold about 50 times as much (although that's questionable given that it was set up backwards it probably can't fully use the uint64). Comparatively, absorbing the world economy and still maintaining divisibility so that tx fees are still reasonable compared to exchange value would require maybe 20 times a uint64 at minimum, given the disparity between current economic status and potential economic output.
More importantly, the means for changing the decimal place rests solely in the hands of the programmers, as there is no user-defined setting for it. That means as prices shift and the currency appreciates, users and merchants will not have any means of shifting what is considered a "base unit", and no way of standardizing what they mean even if they implement that functionality privately. Having to complain to the devs about something basic like that in regards to the protocol really defeats the purpose of decentralization of the currency, or at the very least makes it cumbersome to use.