Since the activation of BIP147 (nulldummy softfork) in 2017, the answer is no, this will fail. Before that point it would have been generally non-standard but allowed.

An input to OP_CHECKMULISIG expects on the stack: (from back to front):

• the number n
• n public keys
• the number k
• k signatures
• a dummy element (ignored pre-BIP147, must be 0 post-BIP147)

In your example, n=6 is read, followed by 6 keys, then k=3, and then 3 signatures. These 3 signatures do match the last 3 keys, which on itself would work. However, after that a 0 is expected, yet instead there is another signature, which fails.

Before BIP147, the signature_3 would function as the dummy, and signature_1 and signature_2, plus a 1 (from the evaluation of OP_CHECKMULTISIG) would be left on the stack.

Since the activation of BIP147 (nulldummy softfork) in 2017, the answer is no, this will fail. Before that point it would have been generally non-standard but allowed.

An input to OP_CHECKMULISIG expects on the stack: (from back to front):

• the number n
• n public keys
• the number k
• k signatures
• a dummy element (ignored pre-BIP147, must be 0 post-BIP147)

In your example, n=6 is read, followed by 6 keys, then k=3, and then 3 signatures. These 3 signatures do match the penultimate 3 keys, which on itself would work. However, after that a 0 is expected, yet instead there is another signature, which fails.

Before BIP147, the signature_2 would function as the dummy, and signature_1, plus a 1 (from the evaluation of OP_CHECKMULTISIG) and 0 would be left on the stack.