just to clarify, schnorr sigs are also needed to remove the distinction between single-sig and multi-sig, as signature aggregation (not possible with ECDSA sigs) reduces all the signatures from separate parties in a Multi-sig address to one (the signatures _are_ calculated separately, but the participants then literally add the signatures together to produce a single signature that validates the transaction)
without schnorr's sig-agg, multi-sig txs would still require the minimum quantity of sigs defined as the threshold minimum in the scriptSig, and more than one signatures necessarily means more than one signer
(unless you're using multi-sig as a security measure where you sign with 2+ devices, taproot/schnorr protects that kind of user from revealing their security practices also)
Terminology danger!
Signature aggregation refers to the case where the verifier (the blockchain) knows a bunch of different pubkeys and you prove that they all approved a transaction using a single aggregated signature. This is the often talked about thing that taproot doesn't include that would help make multi-input transactions much smaller.
Threshold signatures and _key_ aggregation are where some participants cooperate to produce a single key which some threshold of them can sign for, but which to the network just looks like a single party signing. Taproot allows this, and it's what allows you to make multisig like usage which is indistinguishable from single key.
So taproot removes the distinction between single party spends and multisig too (which can include lightning input spends which don't actually use CSV/CLTV, even if they have it available). Indistinguishable threshold signatures may not, however, be usable for all multisig usage because the threshold signature requires a little more interaction between signers and because in some cases you really want the public record to reflect which participants out of the threshold actually participated.
But atypical scripts will still be just as noticeably different as before, the only difference being that alternate paths (i.e. OP_OR sections within the script) will not be recorded to the blockchain, only the path that is actually used to spend the output from the address is written to chain.
Yes, but almost always you can restructure a script as "[All the parties agree] OR [Complicated script thing]". If you can do this, you can put an N of N pubkey at the top, and if the parties cooperate, the parties can cooperate and just sign and and the fact that "complicated script thing" exists at all will not be exposed.
The only time the existence of a complicated script would be exposed is if some parties don't cooperate (E.g. because they're offline).
Perhaps, I've been too critical a few weeks ago when I was expecting some skirmish from miners regarding the upgrade. If that's the pace of miners activating Taproot we should get there in a reasonable amount of time. 
