Sending bitcoins means to lock funds to a specific output script. The output script determines how the funds can later be spent. E.g. if funds were sent to a P2WPKH (Pay to Witness Public Key Hash) address, they can later be spent using a P2WPKH input script. If funds were sent to a P2PKH (Pay to Public Key Hash) address, they have to be spent using a P2PKH input script instead.
The (native segwit) P2WPKH input script has less weight than the P2PKH input script, so receiving funds to P2WPKH addresses will save you fees when you later spend those funds. The output scripts for both are similar in size.
Funds of any type of input can be assigned to outputs of any type in a transaction. You can even mix: spending a native segwit and a non-segwit input, and sending to a non-segwit and a native segwit output in one transaction works fine.
However, as you say, some wallets may not support sending to native segwit addresses. In that case, the receiver should fall back to providing a backwards compatible P2SH-wrapped segwit address which is still cheaper than non-segwit but can be sent to by almost all wallets. You can track native segwit adoption on Bitcoin Optech's Compatibility Matrix or whensegwit.com.
My understanding is that such wallets cannot properly validate Native Segwit addresses and cannot create Native Segwit outputs. Does it also mean that such wallets cannot properly spend the outputs generated by Native Segwit addresses?
Correct. A wallet that does not know how to interpret native segwit addresses would not be able to spend funds received from a native segwit address. This is not a problem in practice, because the receiver provides the spender with the invoice address they want to receive the funds to. The receivers wallet will not generate a native segwit address, when it is unaware of native segwit.
