You mentioned this in your post, but was thinking this before I read it there.
For method 2
The distribution of the 70% has to be beyond the normal algorithm of taking the input DBC(s) and then distributing them according to the RFC stated proportions.
How do we determine section to section how much should the section be adding to each of the stated proportions. Meaning what if one section has distributed a certain amount but another section 1/2 that amount at a certain point in time. This could be because of the number of chunks stored, updated (append), data blobs updated (account blobs etc), app dev rewards given out, etc.
How does the 70% get evenly distributed amongst the differing rewards, does each section get a set portion of the 70%, then what if the original section splits into 2, so each has 35% to give out, then after a period of time one of the 2 split 4 times and the other 3 times. But unevenly which is to be expected. the 35% down one path ends up with 12 sections and some with around 2% and other 4%, the other path has some at around 8%, 4%, & 2%. Does this now mean that if one ends up storing their chunk in one section they get 4 times extra compared with another section?
This is what one would expect if method 2 is used since there is no network wide consensus on how much is to be given out.
Then for the network to know exactly how much exists is another issue if token is created, since there is no set amount created. Race conditions could see the total SNT exceed the agreed total supply by a small amount, or even many % depending on how timely any audit of network wide supply is.
But if say method 2 is used but instead of creating SNT the whole is created in the genesis section and the “pool” DBC the section has is split evenly between the 2 new sections. At least this way the total SNT across the network is not going to increase or decrease. BUT still have the issue of non-equal extra payments across sections given when slowly distributing the 70% as shown in the example above.
Obvious these things can be worked out, but it is a consideration needed.
My thought is that method 2 can be done without actually having sections create SNT but rather have their “pool” DBC which they keep taking small amounts. Obviously the “pool” DBC is not the same since parent pool DBC —> New “pool” DBC + extra payment DBCs for any normal reward payment.