Sounds good. I'll have to go through the math more carefully later. But all those details are "soft-fork" parameters and formulas (other than the account creation tokens state which by itself doesn't mean much) and thus can be easily changed later by witness consensus without a hardfork.

And while on that topic...

This way, in the worst case scenario, if a witness is compromised, the number of accounts that can be created will be limited to the supply of account creation credits.

We want to introduce the concept of subjective reject.
...
This change is the most intrusive to the core blockchain logic as it changes the fork resolution rules. Due to this fact, we will not ship this change in 0.20.0, but in a later release.

While that subjective reject solution is likely the best one and the most general one (not just for abuse of account creation by bad witnesses but for general abuse over things that have soft-fork protections), it may be useful to have further restrictions for this specific new account creation feature, especially since it won't be ready by HF20. One mechanism, for example, that may be useful in further limiting the damage of abuse is to only allow at most some fixed fraction of the daily account creation token rate to be consumed per block; so even if there was demand to create the entire daily limit of accounts instantaneously, the blockchain would still force it to be spread out over let's say a round, thus delaying the account creation by at most 1 minute but also ensuring that a single bad scheduled backup witness could only create accounts equal in number to 1/21th of the daily account creation rate (other trade-offs in time delays and limits to damage by single bad witnesses may make more sense). This consensus rule is easy enough to implement and provides useful protection against abuse with very minimal drawbacks during the time after HF20 is activated but the code for the "subjective reject" solution is not yet ready (and it still remains a useful additional protection against account creation abuse even after "subjective reject" is deployed).

Additional thoughts:

we propose a new method of burning STEEM (i.e. destroying the tokens and removing them from the token supply) on each account creation and crediting the account with permanent minimum bandwidth instead of providing Steem Power to the new account

Would the system log the VESTS amount corresponding to the burned STEEM (or equivalent STEEM value of the PoW or stake used) at the time of account creation and continue using that for the rest of the account's existence to determine its share of this permanent minimum bandwidth? Or would each account always maintain the exact same share of permanent minimum bandwidth regardless of what was the STEEM amount they had to burn (or its USD value) at the time of account creation? Or something else entirely?

Because accounts will now be created with 0 SP, their initial votes will not be worth anything. Removing this threshold will allow those accounts to interact with others on the blockchain while they establish themselves in our community.

Perhaps this should be the time to separate out reactions from upvotes/downvotes in the UI. At a blockchain level, truly dust level upvotes (not the threshold that exists today but a much lower threshold determined by computed curation weights being so small that they might as well round down to 0) would add to the net_rshares of the post but would not create a consensus-level vote object (nevermind, it has to track it at least minimally as part of consensus if net_rshares is to be modified, otherwise it can be abused; insertions in this paragraph are italicized) be rejected. Nevertheless, the upvote would still be captured at the middleware level along with any additional the UI could submit to the blockchain the reaction information provided with custom_json operations to reflect the user's opinion of the post, so that it could be properly reflected in the UI.

By the way, while we are at it could this hardfork also get rid of the annoying time limitations on creating posts/comments. First of all, the consensus memory usage argument does not justify a longer time limit on top-level posts (currently 5 minutes, which is ridiculously long especially for use cases like Zappl) than comments (currently 20 seconds, which is still too much for active post authors responding to comments much less for useful bots). At the very least both time limits should be the same and should be lowered to a more sensible time limit like 3 seconds. But I am not convinced that any time limit is necessary. Perhaps the bandwidth rate-limiting on new comment_operations should be adjusted to have a sufficient fixed amount (to justify the fixed cost of creating a new comment_object in low memory nodes) plus the variable amount that scales with the size of the transaction (to pay for the bandwidth utilization).

Also, on a more technical level, if this account creation redesign requires creating a new operation for account creation to replace the existing account_create_operation, please do not forget to add extensions_type extensions;. This was (correctly) done for account_create_with_delegation_operation but apparently that operation is going to be retired with HF20. The extensions field is useful so that later hardforks can more easily add optional parameters with account creation. My favorite example of such an optional parameter that could be implemented in the future is one that overrides the initial recovery account to be something other than the creator of the account, so that the newly created account can have their intended recovery partner from the very beginning (even when a registrar different than their recovery partner is paying to create their account, or with HF20 if they are mining a discounted account) rather than needing to wait 30 days before the change can be activated.