People who use debugger-enabled builds usually are capable of not mixing
their config files so please don't over-emphasize stuff like that.

This discussion confirms that it may give some problems even to people who use debugger-enabled builds. And those builds may also be used by normal users if they use cvs builds. Also frontends may make a lot of mixing inside config files. It also makes command line options incompatible (what would happen if you type dma=false for example? which option would change?)

It is absolutely not a problem to rename, and there are absolutely no side effects of that.

So why not to get rid of some potential future problems while there is a chance.

And those builds may also be used by normal users if they use cvs builds.

That's their problem then.

Also frontends may make a lot of mixing inside config files.

I don't see any problem with that when using a regular dosbox config file.

It is absolutely not a problem to rename, and there are absolutely no side effects of that.

Yes it's a matter of getting people to realize what matters and what not.
I'm sorry if it took the guy more than a day to get his config file "fixed",
he surely learned interesting things on his way debugging this.

So why not to get rid of some potential future problems while there is a chance.

Because nobody cares.

I considered changing the config entry but didn't. Gus uses the same syntax (section and bool named the same), if it also gets disabled when gus::gus=true and log::gus=false then it's a dosbox issue. I do not have curses installed in my dev tree so I cannot test this at the moment...

This would only be an issue if you use a dosbox config file from a debugger-enabled build with a regular build.