Controller Box Switches have always been what the data list calls destinations as part of the motion control system (Control/Mod -> Control Assign menu in Montage Classic).   

An article: https://hub.yamaha.com/keyboards/synthesizers/mastering-montage-9-controller-box-switches/

And these destinations don't switch things.  Here's my take on why these are called "switches" - it's talking about the underlying fabric - not what's riding on top.  In the old Montage (there are more destinations now) there were 16 destinations per Part.  So each Part had 16 highways that you could place lets say 50 different destination parameters onto.  When you assign a destination parmeter to a control assignment you "switch in" this parameter onto the switching fabric.  And at the other side of this matrix you have the source controller.  So "box" probably means the placeholder for what controllers are tied to and in the box you stick parameters.  Insert shrug here.   

I do know that Yamaha thinks very hardware centric and these can be modeled with electronic muxes.  A mux works like a traintrack you an select between "n" number possibilities with a selection "lever" that connects one thing electrically to another.  And this is the sense of "switch" I believe led to the documentation verbiage.

It's important not to get too wrapped around the axle about what Yamaha calls things.  Things make more sense if you think like a hardware design engineer but what ends up making sense thinking this way isn't necessarily helpful for getting musical results.  In this case (and many similar cases) it's best to ignore that "switch" means anything meaningful because underlying electrical implementation is not necessarily helpful to anyone and just know these are destination parameters -- as is evident by matching them up to the destinations in their respective categories ("generic" control assignments and polyat control assignments).   Something you already had figured out.  I say ignore because lots of times the terminology is confusing or misleading to someone trying to reach a musical end.  

I bet Yamaha has an internal struggle with this having great musicians on the sales/support side that have to deal with the hardware folks who seem to have won the battle for how the GUI should be presented and how documentation unfolds.  How hard would it have been to agree on a marketing term for control assignment destination parameters and labeled the table in more marketing term approved ways?  I'm not even saying "control assignment destination parameters" is a good fit.  But "matrix destinations" seems good enough.  This is a small piece of the overall picture where so many other things are a bit convoluted.   I tend to agree with those that say you need to have an engineering degree to work your way through this stuff.  You don't need to have one - but it helps to sort through some things. 

Ok - gotcha! Those switches actually indicate which controller destinations a component is using.

Based on your comments we tested the Init Normal (AN-X) part by setting destination 25 to 'AN-X Param->Cutoff'

When you do that the screen shows 2 ON/OFF switches - one for filter 1 and one for filter 2 - the default is ON.

The performance dump shows the 25th set of values to be 00 if the switches are both set to OFF.

F0 43 00 7F 1C 00 29 0D 40 03 00 00 00 01 01 01 01 01 01 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 00 01 01 01 01 01 01 01 01 01 01 01 0F F7
F0 43 00 7F 1C 00 29 0D 40 03 01 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 00 01 01 01 01 01 01 01 01 01 01 01 0D F7

You can see the '00' values towards the end of the two dump lines.

The 1st line ('0D 40 03 00') is filter 1 and '0D 40 03 01' is filter 2

That suggests they may have revamped the code to check the switches in the table to determine what destinations a component (in this case a filter) have been assigned rather than check the destination table itself.

Not only would the code be more efficient as the number of possible destinations increases but it also lends itself to (in a future update) exposing those 'switches' in scene memory where users could take advantage of them.

Your extended comments were most helpful!

Testing shows those really are SWITCHES and will turn the corresponding controller assignment ON/OFF.

When a switch is turned ON the values for 'source' and 'destination' will be the last stored values for that control assignment slot.

f0 43 10 7f 1c 0d 10 00 09 20 00 01 f7

The above command turns ON (enables) Poly AT destination 3. The table on p241 of the Data List doc contains the Poly AT parms.

As the table shows the Hi, Mid, Low address bytes are '10 00 09' where '10' indicates part 1 (0-based values.

The '20' is the offset into the table for 'Key Controller Set 3 Switch' - NOTE the table actually shows 00 but the switch offsets are incorrect in the table for switches 1,2 and 3.

If you have previously assigned destination #3 and turned the dest #3 switch OFF the assignment isn't deleted. It will still be there when you turn the switch back ON.

Assignments are saved in memory when they are made but aren't persisted until you STORE the performance after making them.

So you can, if you want, make a lot of control assignments all over the place and then use SysEx to turn the switches to OFF for the ones you don't want to use right now and those assignments will still be there later if you want to turn the switches ON to use them.

The 'gotcha' is that currently there is no way you can manipulate the switches directly in the UI.

Might make a nice future enhancement to:

1. expose the switch matrix in the UI

2. allow the switch matrix to be manipulated in scene memory and on the actual assignment screens

Thanks to Jason for identifying what the parms lables 'Controller Box Switch' really are. Just a note but the switches for the AWM2 engine do NOT have 'box' in their name.

I was making the distinction that the names of each of the things in the box isn't a switch.  Something like "Element Level" isn't a switch to turn on and of an element level - but it ends up being a value that can be 0-127.

Having yourself essentially explained everything in your own previous message it was difficult to figure out what the remaining question was.

I guess we got there through a windy path - better than not getting there at all.  And there's more scenery on a windy path.

It's not necessarily a bad thing that not every construct you can do with low-level programming ends up in the GUI.  Although I'd prefer to have more knobs and buttons (I'm talking in the GUI) to do everything possible - and I'd prefer an "Advanced mode" switch to hide all of the gory stuff from the casual user -- I completely understand not doing this.  The more functions and features you expose and support the more test cases you have to run through at Yamaha to maintain the code.  And every time you re-release firmware you have to regression test everything checking even these "hidden" advanced features aren't broken.   At some point Yamaha made an executive decision not to do certain things that are possible.   And at some point you (or, at least I) give up asking.

One of these I thought would would be extremely helpful would be to allow creating user curves to define every possible value instead of the 8 we were allowed to define (8 step or 8 vector).  I wasn't even asking to add a GUI interface but at least a SysEx way to do this or ... just some way.   And lack of movement tells me it's below the cut-line of what Yamaha wants to support in terms of coding maintenance and also documentation and support calls/forum/etc.    There are other reasons probably too (such as retaining firmware control means that you may have to wait for another generation of the keyboard to get curves supplied by Yamaha instead of programming your own which is an influencer to upgrade - and also just fueling a reason to have an external editor people buy like the Melas tools).  Also asked for the operator on/off switches for FM-X that are the same as the DX-7 which more match this example of being able to turn things on and off without deleting the underlying assignments.   Those operator on/off switches are analogous.  But instead we adjust to what's given to us maybe at some loss of niche functionality while our programming hat is on.    Maybe add another purchase of software to do the thing that's missing in the GUI.  Maybe write our own software (for those that can). 

To be sure the need for testing, and regression testing, is a prime consideration when changing code.

A major impact on the degree, and type, of testing needed is the extent to which new functionality impacts or interacts with existing functionality.

Obviously can't speak to Yamaha's code directly but the switches themselves already exist and can be manipulated by SysEx. That would at least imply that testing has already been completed to ensure that works correctly.

Exposing a switch in the UI would typically be entirely self-contained and not interact with any other module except the same code the SysEx would already used to change the state of the switch.

I wouldn't expect that adding a visual switch representation to an existing screen would impact much of anything. But you never know. It is the type of work you can give to a junior programmer because it has such a low potential for affecting existing code.

Compare that with being able to turn an arbitrary operator ON/OFF or, even more daunting, allowing user creation of operator algorithms where operator can be linked as desired.

That would have some serious potential failure points including infinite loops if operators link in circular fashion. And that is just to get the code to work at all.

On top of that you have to test the actual dynamics of the executing code in terms of amount of resources used, execution times, syncing of multiple processes, etc.

That is the sort of thing that take some SERIOUS up-front design work before you can even begin writing code. I loved doing that kind of work but am glad those days are behind me and can mostly deal with mundane issues like doc errors.

Lots more ripple effects to any feature so I'm sure Yamaha has cut lines that only get rethought if enough people clamor for the feature and present a compelling enough use case.  Operator on/off has the new way to do this.  A little lost functionality but not much.  Same with exposing what would probably be marketed as "links" within control assignments to match the kind of system assignable knobs have linked to super knob.  I get the particulars are different but the language around this system could match.

So ... Cast your wish and see what happens.  Play the long game if you have the time and patience.  

Personally, even though there are lots of things I would like done that are similar to this request, I would rather the firmware focus be on things that can't be done no matter what steps you take.  FS1R formants, GS style algorithms, arbitrary user curves, SA (super articulation), arpeggio editor with advanced options, user waveforms with compression applied internally (and saved as compressed format), more non-vibrato samples to refresh super old preset waveforms (country violin or fiddle makes me cringe - too many "sweet' instruments).  Etc ...  Not sure clav was at the top of my list of targets to improve.  I've been using clav without cringing.  Lots of stuff even old stuff (legacy samples) are great.  But there are obvious weaknesses that could be explored and fixed.

Since I use clav having another one that may cut through better or complement better what the guitarist is doing is welcome but just wasn't at the top of my list.  Somewhere there's a happy A-list pro.  Guess this is where 3rd party content may need to come in.