I'm not opposed to the idea in principle, but it might be hard. or at least clumsy, to implement.
!WriteKeyValue and !SetOption have two entirely different things they work on. !WriteKeyValue is based on any physical "file", and !SetOption / !SetVariable are based on any currently running "config". To create a single bang that addresses both of these at once might mean a syntax that is almost more confusing and hard for skin authors to write as the longer, but straightforward use of two bangs is today.
It would certainly mean changing how "default" options are used in the bang(s), as today the default for !WriteKeyValue is the current skin .ini file and the default for !SetOption is the currently running config. You can't easily have two optional, default parameters in a bang in our current method of parsing bangs in the code. So I suspect you would always have to spell out the file to write to and the running config to impact, and that would be regrettable.
!SetKeyOption SomeSectionName SomeOptionName "Some Value" "#CURRENTPATH#SomeFileName.ext" "Some\Config\Name"
It wouldn't be difficult to default "both"
!SetKeyOption SomeSectionName SomeOptionName "Some Value"
But a challenge, and probably confusing, to default "either / or". Parameters in bangs are "positional" in Rainmeter. it could be doable, but it would mean that to define the "config", you would HAVE to first define the "file". There is no such thing as a "default" parameter indicator in bangs today, and I would be hesitant to try to introduce that concept.
That concept of a "default" placeholder in parameters does exist today, but only in specific isolated cases, like the
Shape Meter. In that case, we use the
* character as the placeholder, but that would never, ever be possible in a bang, where
* already has a specific meaning.
This seems like an idea that feels really good on the surface, as in specific cases, granted probably often, where you are writing to the current skin .ini file, and at the same time want to make a change to an option or variable in the current running config, it would make things shorter and has a lot of charm. However, it seems like it would only be good for that specific case, and would quickly devolve to something a lot less charming when the circumstances are different.