the link mentions lightning network.. so lets explain ALL the proposals
[tl:dr;
none of these help increase the tx/s ONCHAIN. all they do is add new features but reduce the impact of the new features to try to prevent a drop in tx/s]
1. lightning network
this is a SEPARATE NETWORK for ANY compatible coin to use. it works by locking up any compatible coin as a unspendable UTXO for a time period on the coins network and requires co-signing by someone else.
LN is not a bitcoin feature. bitcoin had to become LN compatible. not LN had to become bitcoin compatible
on the separate network it will require masternodes to be online and monitor multiple chains to ensure channels that allow atomic swaps to have 'trust' that funds from different chains are remained locked while channels play with 12 decimal values that are unconfirmed/unaudited.
LN is not about scaling bitcoin. its about taking utility away from the bitcoin network to cough give relief cough to bitcoin by having less users using the bitcoin(other coins too) network(s)
LN does not help the transactions per second scaling in bitcoin, it take transactions out of the bitcoin network
2. mast. this is where certain utxo get locked unless certain conditions are met.
usually involves bloating up a transaction with alot of script. thus reducing the tx/s but mast uses secondary transactions to spend the first transaction when condition is met. there is still a bit more bloat than average per tx and still if you add up the child and parent transaction together still end up being alot of bytes used combined to make value spendable... but does not help the tx/s scale up
merkelised syntax tree's are just buzzwords which means it simply tries to avoid making the tx size average for the last ~10 years become a bloated higher number. by requiring a child transaction
but does not help the transactions per second scaling in bitcoin, its to try to avoid less tx/s when people use smart contracts
3. schnorr. similar thing to mast. it doesnt help increase tx/s it simply tries to avoid the average transaction size becoming more bloated transactions of new formats, by cutting down the signature bloat. again not helping to increase tx/s but does avoid a reduction of tx/s when new smart contracts are added
4. sidechains. again like LN involves locking up funds on bitcoin network to then make transactions on another chain. again it will require masternodes to monitor both chains. but does not help increase tx/s throughput of bitcoins mainnt. it simply pushes utility off the mainnet.
5. bulletproofs tries to hide how much is being spend. though this ends up opening possible bugs of fungibility and requiring trust of fund origins rather than a transparent audited ledger. it also does increase the computational processing of such transactions which is not helpful if suddenly everyone used it. as the propogation times of rlaying a block would increase even if the tx count is the same
6. confidential transactions is another way to hide how much value is spent but does require large scripts bloated to a tx. the core devs simply think that segwit done its job right by not having to count the scripts. yet to a CPU and a hard drive that do actual processing they do actually see and process the bloat.
summary
none of these help increase the tx/s ONCHAIN. all they do is add new features but reduce the impact of the new features to try to prevent a drop in tx/s although we have already seen that transaction bytes have increased and average tx/s has decreased (satoshi said in 2009 if we stick with lean 1in 2out tx we can have 4200 tx a block (7tx/s)
with new features SO FAR we are averaging only 1750 tx a block (3tx/s)
these features want to avoid bloating the network to not become under 3tx/s or take transactions off the network completely so that those that want to stay transacting onchain can continue with the 3tx/s average
