How could Schnorr signatures be aggregated across the whole transaction? I am studying the MuSig protocol and am having trouble grasping certain segments. This is my understanding thus far:

In current Bitcoin CHECKMULTISIG format, the size of the signature grows linearly with the number of additional "m" signers. The way CHECKMULTISIG works is that each signer produces their own independent signature, and we embed all these individual values in the scriptsig. So, a 3 of 5 unlocking script might read [sig 1][sig 2][sig 5]...for simplicity sake I will be calling this compilation of all individual sig values the "group signature". In the given example, this signature field would be 3x the length of a standard P2PKH.

In a "naive" Schnorr multisignature scheme, rather than dropping all the potential public keys and [much larger] group signature onto the blockchain for verifier computation, we can have the signers interactively sum their individual public keys in a precommitment phase to derive a single "aggregate" key, that reads synonymously to a traditional public key. An outside member could then send BTC to this aggregate key, where it would be controlled by the group members. For the group to spend, each party would create a partial signature using their unique personal keys, and interactively sum all these signature values to create a group signature. At this point, we are left with a group signature (that is the size of a basic P2PKH sig) and aggregate public key being appended to the blockchain, providing us great space savings. However, this scheme is insecure unless operating under a KOSK model. We turn to another Schnorr variant, MuSig, that can offer provably secure key aggregation while operating in the plain public key context.

The 2018 Blockstream blog post states:


  Instead of restricting ourselves to one signature per input, we can actually get one signature for the entire transaction. Key aggregation can’t be used across multiple inputs, as the public keys are committed to by the outputs, and those can be spent independently.


I am having trouble understanding this paragraph. I am guessing that each aggregate key must be referenced in the scriptsig, since the previous sender's scriptpubkey would have mandated proof in order to unlock the encumbrance. I am struggling to understand how the aggregated signature across multiple inputs part is accomplished.
This is a feature of Schnorr digital signatures (ECSDSA) that did not exist in the digital signature scheme (ECDSA) that we are currently using. You should not compare the two multisig schemes together, the current design is a workaround.

Schnorr allows you to "aggregate" multiple signatures into only one signature by combining both private/public keys in the process of signing and produce a single signature (r,s) based on them. As a result you should only see one signature and one public key in your Schnorr transaction scriptSig and the output scripts (scriptPubkey) should also only use a single public key.

Take a look at this answer for a simplified collective signature scheme to get the general idea of how we only have one signature/pubkey, MuSig adds some additional steps to this process to prevent certain attacks.