Two problems weigh heavily against using Program MIDI messages to control slot selection in more than one dimension (column) in one Sy Player. It appears you've already noticed the first of these problems, but I'll lay out both here for the sake of other readers who may not yet have got as far as you.
Problem 1. First let's consider using MIDI Program to control 1 dimension only. Let's say this dimension has 8 slots, and you've specified Program 10 in the dimension controller box at the top. You send Prog 10, and the top slot selects.; then you send Prog 17, and the bottom slot selects. And each slot in between can be selected according to 1-to-1 mapping, as you'd expect. All fine so far.
But then you send Prog 9, or 3, or 0, and the top slot selects. Then you send Prog 18, or 20, or 30, and the bottom slot selects.
That's the first problem. Sy Player doesn't treat MIDI Program in the same way as MIDI Note keyswitches. Out-of-range keyswitch notes do not affect slot selection, but out-of-range Program numbers do.
So it's not feasible to control more than one dimension with Program by assigning each dimension its own range of Program numbers, because there's no way to make a range of Program numbers exclusive to one dimension.
Problem 2. Even if VSL changed Sy Player's treatment of MIDI Program such that out-of-range Program numbers didn't affect slot selection in any one dimension, there's still another problem.
Assuming VSL had already made this hypothetical change, and say you have a piece of music in which MIDI Program is carefully automated such that it's controlling 3 dimensions in one Sy Player (strictly in left-to-right order of course). Then say you want to review or edit some part in the middle of your piece of music, and so you start playback at that point. What will be read from your Program automation at that point probably won't be what you expect or want.
This is because your Program automation sequence typically would have to deal with dimensions in left-to-right order, but if you then start playback from some point farther to the right, only the last Program automation value at that point will be read, which logically may not reproduce all the dimension slot selections appropriate to that point in the timeline.
Sure, you can always set the play pointer farther back to some point where you know the dimension control automation sequence from that point onwards will select all the required slots (or you could even switch off that automation and select slots manually), but how inconvenient would that be every time you want to start playback somewhere else?
"Solution". It's best to use as many different classes of MIDI messages as there are dimensions we wish to control in any one Sy Player. (Each MIDI CC number counts as one class, Program is one class, Note is one class.)
Even so, then comes another issue that several users have already flagged up: it can be a very complicated and onerous chore to set up or modify automation for dimension control in many differently-structured Sy Players in a template or a piece of music.
This is because when using Dim.Ctrl (A up to H), setting the value of an automated MIDI CC message to select a particular slot means we must first know what range of MIDI message values will select that slot - Dim Ctrl always uses proportional mapping across the full scale 0-127, dividing the scale into equal(-ish) chunks according to how many slots there are in the dimension. That proportional mapping is great for X-fading in Parallel Mode; but for simple articulation switching, not so much.
Sy Player really is a paradigm-shift in the world of sample-based virtual instruments. As a result, our so-called "horizons of expectation" (or what we intuitively treat as "normality") have of course been thrown into a somewhat confusing state of flux. But as history demonstrates, successful innovations become "naturalised" in time. Soon enough no doubt we'll be wondering how the world of virtual instruments could possibly have got along before Sy Player! Lol.
