On chain cost of Segwit version 1 versus version 0 How do total blockchain cost for Segwit version 0 compare to version 1 which is being proposed? I'm specifically interested in a single user transactions – both paying to public key (or pk hash) and script (mostly asking about scripts without branching as I understand there are savings in more complex scripts with more branches). By total blockchain cost, I mean the number of bytes, vbytes and weight in both the outputs as well as the inputs that are spending these outputs. In other words, I'm asking if there will be any savings in version 1 scripts compared to the transactions that can be done on version 0.
In general, Segwit v1 is cheaper than segwit v0 to spend but slightly more expensive to create.

Segwit v1 output scripts as defined by the proposed taproot BIP will always be 35 bytes in length. However Segwit v0 output scripts are either 22 bytes (for the single key case) or 34 bytes (script hash case). This means that the person sending to segwit v1 will end up paying a little bit more than for a segwit v0 output. Of course, the recipient can use P2SH wrapped segwit outputs so that cost would actually be pushed to them.

However segwit v1 is cheaper for the recipient when he wants to spend that output. Because segwit v1 is a Pay-to-Pubkey model, the public key does not need to be specified in the input. This saves 34 bytes of witness data (34 weight units, 8.5 vbytes).

Additionally, segwit v0 uses ECDSA signatures which are encoded using the DER encoding. This results in signatures that are typically 71 or 72 bytes (each size has ~50% probability of occurring for any signature unless the software specifically only creates 71 byte signatures like Bitcoin Core does). But segwit v1 uses Schnorr signatures and the encoding specified for that in the BIPs which will typically be 64 bytes in length (can be 65 if something other than SIGHASH_ALL is used but that is rare). For simplicity, we can say that this is a reduction of 8 bytes which is 8 weight units and 2 vbytes.

So for the typical single key case, segwit v1 saves 42 bytes which is 42 weight units or 10.5 vbytes.

Where it gets intereseting is the case of multisigs, the most common type of script used. For multisigs, the MuSig multisignature scheme. MuSig allows a n-of-n multisig or a m-of-n non-accountable multisig (i.e. no one will be able to know who signed) appear to observers as a single key signature. This means that there is only one public key specified in the output and one signature verified in the input. So for all n-of-n multisigs and non-accountable m-of-n multisigs, the cost is exactly the same as for the single key case, but the savings vary depending on the number of signers. The savings for the first signer are the same as the single key case. For every additional signer (i.e. when n > 1), using segwit v1 saves ~107 bytes, which is 107 weight units or 26.75 vbytes.

It gets more complicated for m-of-n signatures where you want accountability.  Such threshold signatures can be achieved by using MuSig and a merkle tree that represents every combination of signing keys. However the size using sewit v1 will ultimately be smaller than segwit v0 because ultimately, the leaves of the merkle tree will always be single pubkeys and the hashes in between will be slightly smaller than public keys in a traditional script. Lastly, the most common of the thresholds can be used as root case in taproot which allows for more savings as then branches of the script don't need to be revealed.