Unlike most other blockchains, a steem wallet is always a light wallet, it queries a full node for the current state.
I don't know what can be done to prevent the necessity for RPC nodes to replay, I would think that will take a substantial change, that is, graphene would have to be removed, replaced with a better engine like Dgraph and maybe some kind of large blob specialist data store for the forum, and then, without constant changes in the format of the shared_memory, it could be possible to use a bittorrent protocol to propagate snapshots to quickly sync new nodes.
The reputation calculation will be easy to determine, it just requires tracking the highest reputation score account and then performing a calculation against the account to generate its resultant vote weight.
Number 6 means that when you activate a witness, your normal witness votes are not counted, and instead just a single vote for your own witness replaces it in the calculation. When the witness deactivates, your witness votes are again added to the calculation for the others. Obviously this implies you can't vote on other witnesses when you are running a witness. This is to stop collusion and blackmail between witnesses, when there is witnesses with high reputation and stake. And yes, reputation will also limit the witness vote weight calculation.
Stopping indirect self votes will be possible to do on a community level, where people can investigate links between two suspected sybils, and when these links are substantial, people can then smack down the both accounts and counter their misbehaviour.
The curation split will mean bigger rewards, but remember, every post will be by default self-voted, so, in accordance with your reputation score, you will always have the first share of curation reward that will add to your author reward. They are all going to be only in stake, but stake withdrawal proceeds as a 1% conversion of remaining Stake per day, which makes your account more liquid and eliminates weekly peaks in powerdown cycles (it will become intraday, which is by its nature going to be less volatility).
Shimmer is the name of the fork of the Steemit web interface, that you are probably using right now. Shimmer refers to the way that hummingbirds move so fast you can't see their wings properly, and how fast they can move left and right, like a mirage.
To calculate how quickly you can draw down your account, take the number 0.99, and put it to the power of the number of days, basically, it simply cannot be completely drawn down. After 365 days, there will still be about 2.5% of the account balance of Stake remaining. To illustrate this, here is how much will remain after some number of days:
after 7 days 93.2%
after 28 days 75.47%
after 90 days 40.47%
after half a year (132 days) 26.53%
after 365 days 2.55%
Essentially, this would function to enforce minimum balances, without making them a limit that leads to an account being unable to transact. It's kinda dumb to be able to draw down an account until it can't be used! I think in theory you could have it do that, or, more logically, the consensus could say that if the next payout from drawing down your Stake, that it will disable the power down, if it would take it under the minimum.
Not handling boundary conditions in a user friendly way is not the way I write code. This is one of many clear examples of not handling boundary conditions you can find in the Steem code. HF19.1 included a fix that was causing witnesses to waste time calculating interest on SBD when it was set to zero! The proper algorithm should first check 'is interest nonzero?' which is a very simple and quick test that saves calculations. This is called 'lazy evaluation'. The code does nothing, if there is no reason to do anything, instead of multiplying things by zero to get the amazing answer of zero.