I think some DOS software/games may have problems when parsing a too long BLASTER environment variable.
To fix the problem you just can type "set BLASTER=A220 I5 D1 T1" or something like before starting the critical program. There is no need to change that in device manager.

It's not a Windows issue per se, but an issue with each specific DOS program and it depends on how it parses the BLASTER variable internally. My guess is that older games may have issues with the H6 and P330 parameters as those are specific to SB16 and newer AFAIK. You can simply create a batch file to run the problematic game and set the BLASTER variable with the "pre-SB16" format right before starting it, something like:
SET BLASTER=A220 I5 D1 T6
GAME.EXE
Optionally, since you're are running under Windows, you can change the DOS program's properties and define things like memory and environment variables , try right clicking the DOS program, then properties/program/advanced. Guess you can change it from there.
I remember the sound setup program for Super Street Fighter 2 freezing if the BLASTER variable was anything different than the older format, also had issues with the demo of Chasm: The Rift which for some reason could not identify my SB Pro compatible card (T5), had to set it to T4 for sound to work, Hocus Pocus also relied on the older BLASTER format to detect the sound card properly.

It is a problem with some DOS software like the others said, not a Windows glitch. Removing the H and P values from the BLASTER environment variable should fix it.

For Hocus Pocus, I only had to remove the P value for the game to work with a SB16 sound card.

I think the same.

Considering how poorly some DOS programs parse switches aka parameters (like /?), it's likely that this is the issue.

I assume some DOS programs not only expect a certain set of values, but also in a specific order.

Here are some examples (SET BLASTER = A220 I5 D1 T1)

In worst case:
It opens c:\config.sys manually and looks for "SET BLASTER =".
If found, it will load the whole line as an input.
It will check for 15th, 16th, 17th numeric characters (220) and load them as input (value not string) for port address.
It will check the 19th numeric character (5) and load them as input (value not string) for IRQ.
It will check the 22th numeric character (1) and load them as input (value not string) for DMA port.
-> If it has a minimum amount of intelligence, it will filter out the space characters first.

Or, different, pre-defined versions of the blaster line are being proccessed after each other (with different spacing).
The detection "code" will restart each time, if the character is not a number (this causes an error in the compiler's runtime):
SET BLASTER= A220 I5 D1 T1
SET BLASTER =A220 I5 D1 T1
SET BLASTER=A220 I5 D1 T1

For each version, a different offset is used.

Edit: In the very worst case, the whole mess will be case-sensitve, too! 😉
So better not use "set BLASTER =" or "Set Blaster ="..

In a bad case:
It asks DOS for the environment variable for "SET BLASTER =" and gets "A220 I5 D1 T6" reported back.
Then it parses (if we can call it that way) A. It looks for a value that follows the letter/string A, and finds numeric value 220.
Then it parses I. It looks for a value that follows I, and finds value5.
Then it parses D. It looks for a value that follows D, and finds value1.
Then it stops and ignores the rest.

Normal case:
It retrieves the data for the "SET BLASTER =" environment variable and checks for A, I, D, H, P and T.
The parsing works no matter which order is used. Extra spaces don't cause confusion to the parser, either.
It will then check the numeric values for these letters one after another and put them into the appropiate inputs.
Then, the initialization routine uses them directly or the values are being passed to another program.

Anyway, these are just some examples to help understanding how things can work.