the proposals (BIP118 is just one such proposal) for no-input opcodes don't malleate the transaction hash, that's not possible anymore.

They do alter (or malleate if you prefer) which input is used after the transaction has been written (but obviously not once it's confirmed)

This makes payment channel protocols much better. Using them for on-chain transactions has no benefit, and comes with the risk you mention; if you reuse an address, and you sent a no-input transaction from that address once before, someone could replay the old transaction to spend the newer input, as the old transaction didn't specify a particular input (hence "no-input"). But no wallet developer is going to give you the option to use no-input onchain, that'd be dumb

still, the devs have been talking about exactly how to design the no-input feature for maybe 1 year now. they're being very careful, because it's definitely possible for the user to shoot themselves in the foot if they get too inquisitive and start trying to use no-input in transactions without understanding how it could backfire on them. It's not possible to do anything like that in Bitcoin transactions now, all the footguns were taken out of the scripting language years ago