he didnt choose 21m btc and then calculate backwards that over X years backwards means the base genesis has to release 50btc
I also agree with this, and it makes sense compared to the email posted above.
logic and common sense of decisions plays out as
wanting a currency that deflats(halfs its release amount every so often but not too quick to cause chaos and also not run out of coins once hitting total supply too quick
he chose 33bits where removing one bit off the end per sesion halves the amount of units it converts to in normal human readable numbers meaning 33 halving events.
then the next logic was the halviing events should be not weekly or monthly or yearly but ~4 yearly so that after 33 sessions it means it would take over 130years to get to total supply cut off
he then seen the binary conversion to of 33bits was a large number of units
8589934591 which seemed a huge number of units to offer. so decided on the decimal of 8 (/100,000,000)
85.89934591
but seen that the halving would cause issues right from the start of halving a 1 and next session halving a 9. where by some value is lost immediacy by by rounding
so decided a more even number to start so chose the 50btc as a nice number
by which point if working out that if he done the halving at 210k block intervals =21m coins.
it was then he decided how fast that would be by realising 210k intervals if 4 years was the goal per interval
would mean 52.5k per year, 2019.27 a fortnight (bad decimal amount(cant have .27 of a block))
so he then put in the 2 week adjustment(difficulty formula) to try to keep it to a nicer round number of 2016 blocks a fortnight, which then calculated down to a block ~10mins which seemed a reasonable amount of hard work time to create a block and send it around a network without causing issues with data broadcast delays between peers