All Bitcoin address that start with 3 are nested segwit addresses.
Completely wrong.
You can't. P2SH addresses are identical to each other and there isn't a way to tell if they're a musig (except taproot but that isn't the point of the question) or a P2WPKH nested in P2SH (for simplicity I refer to this as P2SH-P2PWKH) address/other locking conditions. The only time you can differentiate the kind of address is when they sign and spend any UTXOs, the redeem script will reveal what kind of locking script it has.
You don't have to care if the address that you're sending to is a segwit address or not. It doesn't make a difference. As long as the inputs are segwit, the size discount applies.
I've sent two transactions, one to a P2SH-P2PWKH (non-bech32) address and one to a multisig address.
To a P2SH (with multisig) address: efbc21dd2e2a1dc3ff67f853b550b5bab26f3f1a7f7960b0949bd0133f5d9e03
To a P2SH-P2PWKH address: 4a32b0eafad34f5c51c31cde881ecccd5d8a596400abd8b6269608492c6af719
For both, the size is the same at 142vbyte as the conditions are the same except that they're spending to P2SH addresses with different unlocking requirements.
For both, the output script is similar: OP_HASH160 [RIPEMD160(SHA256) hash here]OP_EQUAL
However, when I spend them:
From a P2SH (with multisig) address: 015739847a882dd1d3fb6c1792682cedb0d4155c4f508909cc280d3edf9bfad0
From a P2SH-P2PWKH address: 9dbf5fa4b8b8ffcedceb10ea59be46bb6aeec2b50f817a02a565ed314ea866e2
You can observe that the redeem script contains the requirements to unlock that script and/or the HASH160 of the original address and it's witness.
There are of course a myriad of conditions to be used in a P2SH address but I chose Multisig as the simplest and most common form of it as a demonstration.