wrapped segwit where inputs can have both an input script and witness items.

Is this about Nested P2WPKH & P2WSH ? I might have to redo this part again to fix this

Yeah, that’s right. Nested P2WPKH/P2WSH is another term for Wrapped P2WPKH/P2WSH.

it should maybe be pointed out that in the serialization the witness structure is separate from the input and output sections.

Yes, i'm using the same TX structuring as what currently used by Bitcoin Optech Calculator. I don't mind separating the witness part with dedicated space though

Yeah, we did not make that distinction in the calculator, because the weight of the witness stack directly is dictated by the input type. However, as soon as one input has a witness stack, you need a witness structure, and a witness structure must contain a witness stack for every single input. For non-segwit inputs the witness stack consists simply of a witness item counter that is 0, but this means that the weight of non-segwit inputs goes up by one weight unit when they are combined with segwit inputs.

You can see the separate witness structure for example in the yogh.io explorer that nicely visualizes the transaction serialization (I picked a 2-of-3 wrapped segwit example from your list above): https://yogh.io/tx/23e2e8453fd9d00fc38833e996e042c35d60f5ac2196a2462a44930323694c17/

P2SH 2-of-3 should be 293–297

Now that is confusing, i still don't understand how can the same address have different scriptSig (what could possibly caused that ?)

Here for example :
https://mempool.space/tx/c7d8845045a4f3bd998bc1dbe63928f1e22029e5b056c00a56c2e478a2a08960?mode=details
The 5th input has :

• TX ID + Vout = 36 + 4
• scriptSig length = 3
• scriptSg = 255
• Total = 298

And not just once, the second example also behaves the same

This one example has even bigger input size :

• TX ID + Vout = 36 + 4
• scriptSig length = 3
• scriptSig = 286
• Total = 329, is this a non-standard example ?

Ah, fair point. I haven’t verified, but given the date of the transaction I can still suggest a possible explanation. ECDSA signatures are not fixed in size, among other things, the r and s component of the signature varies in size depending on whether the value falls in the upper half or lower half of the value range. High-s signatures became non-standard after 2014, given that your example is from 2012, I expect that some of the signatures are high-s.

P2SH-P2WSH 2-of-3 should be 139–139.5

For input size 139 vB & 139.25 vB i can find example of that, but haven't found any example of 139.5 vB input size

b426792a6f8f78e59172c1a65db1da4b60797162f9081b6f7a8b31665597d537 should fit the bill.

Thanks, may i ask a favor for one or two mainnet example of P2TR 2-of-3 scriptpath tho, it's for research purpose i promise

Sorry, I don’t have one on hand from the top of my head, but I will think about how to find one.