I wonder that I'm unable to see how exactly BIP 0341 forbids v1+ segwit from using bech32.
BIP341 has nothing to do with this; it specifies consensus validation rules, not address encoding.
BIP350 however specifies that Bech32m must be used for v1+ segwit, and Bech32 for v0 segwit. The older BIP173 specified that all witness outputs (v0 and v1+) use Bech32.
Does consensus allow combining v1+ segwit programs with the bech32 format?
As far as consensus rules are concerned, addresses do not exist (only scripts do). Conversion from/to addresses is something done by wallets (and other user-facing software), and thus if such software follows BIP350, they'd use Bech32m for v1+ segwit outputs.
Old pre-BIP350 software however might use Bech32 for such outputs, meaning such software won't accept addresses created by BIP350-compliant wallets. This is deliberate (from BIP350):
Experiments by Taproot proponents had shown that hardly any wallets and services supported sending to higher segregated witness output versions, so little is lost by breaking forward-compatibility. Furthermore, those experiments identified cases in which segregated witness implementations would have caused wallets to burn funds when sending to version 1 addresses. In case it is still in use, the chosen approach will prevent such software from destroying funds when attempting to send to a Bech32m address.
Does consensus allow combining v0 segwit programs with the bech32m format?
Again unrelated to consensus, but BIP350 does not allow this (and neither does BIP173).