I actually dug into the handbook and messed with the ocp for quite a bit, unlike the big noob I was before. And as I observed, you weren’t wrong about the instrument section being a hard coded hell. I’ve come up with some ways to improve it (not considering code difficulty), what’s better, since few people are making use of this feature, it won’t hurt too much to change it!

The first thing I see, is that the instruments are done by manipulating sections on a single texture sheet. It has it’s benefits: keeping the texture folder clean and organized, easier to tell which section goes on which instrument, and easier to handle visibility variables.

But here comes the first downside, which you just encountered: it has limited space. I know no one will probably ever use up the whole sheet, but having such limiting system isn’t ideal.
Here are some possible solutions:

1. Don’t limit the instruments to a single row. Let the json queue sections with coordinates, so multiple gauges can share pointers and light overlays. Still confined to a single sheet tho.
2. Split everything. Separate them into single image files, and queue them in json using file names. This way, we can have free resolutions (as long as it’s power of 2 and is square), and unlimited gauge counts. However, things like gear indicator will be impossible without some sort of new variables.
3. Considering the above two, this one may get rid of all the issues. Separate each gauge into 128x1024 images. The gauges will work exactly the same way as before, and the file name can directly match with the json name. However, its still limited to 8 slots and 128 resolution.
   It might be harder to make it expandable.

Secondly, and something more complicated, is visible area. Unlike the existing visibility variable, its literally where this gauge will be visible. Currently if you rotate something big like a big square, the points will stick out of the edge of the gauge, and thats weird. Limiting the entire gauge to its size, and making anything out of its bound invisible will fix that. Maybe push it even further and let us customize visible area.

Third, unintuitive visibility variables. I can tell this is a cool and interesting feature, but its not very versatile. Mainly because its limited to vertical and we cant customize the width. I dont have any improvements ideas for this yet. Maybe something along the line of translation, rather than a filter mask thing.

Lastly, digital number displays. Wouldn't be too hard since the gauges are driven by values, which can be fetched and display in number form. This can replace the quirky visiblility speed bars as it takes up a lot of space and has height limit. All we need is to specify the size and position its displayed.

Most importantly, insturment select screen scroll. Been discussed but never a real ticket.

Also your flaps gauge.

I would love having the ability to have unlimited gauges

Had some time to think about this. Let me address it now.

1. Changing the system to not limit to a single row is quite possible, and would indeed free up a good amount of instrument texture space. Additionally, I'm finding that nobody is making their own gauges for cars and boats, so I really should just combine the gauge texture sheets for similar vehicles into one. So planes and airships share a sheet, as do cars and boats. In general, ground vehicles get one set of instrument textures, and air-based vehicles get another. Third option would be to require a texture variable for the JSON, but that'd break all packs and cause crashes everywhere, so I'm not sure I want to do that. Especially since nobody is even close to maxing out the texture sheet with unique gauges. No re-colored gauges don't count as unique!
2. On that note, I won't be splitting textures. It's very hard on the GPU to do a bunch of texture bind and re-bind calls, all with rotations. This will become even less of an issue if I implement point 1 and make it so gauges don't have to be arranged in columns, as you'll get about a 80% reduction in texture sheet usage due to non-duplication.
3. As to this one, I sure as heck ain't going to load MC up with huge textures. There's already issues with it handling big textures with UNU packs, and once again, if I free up the instrument texture sheet the lack of texture space won't be an issue anymore.

Visible area could be better, though making the visibility "window" stay static while the texture rotates is far harder than just rotating the texture. The former requires trig, while the latter is just a rotation. Still, it would fix a good amount of the odd rendering issues that plague fancy gauges.

As to the actual visibility implementation, that is something I really should re-visit. While you're not going to get automatic number displays, you should at least be able to get something like rolling number displays by using the appropriate factor and arranging the numbers vertically so when you go past 9 you "roll over" back to 0 at the top of the sheet. Think car odometers and the digital dials on jet airliner displays. Custom width would help with this, as it'd allow for a more compact sheet where two gauges could share a column, though this might be harder to do than I would think. Need to investigate.

In all cases, this comes down to a fact of usage. As you said: nobody uses this feature. So it's not something I'm going to go all gangbusters on when the majority of people just apply skins to the gauges and then leave it be.

Though that does raise a question: should I change gauges so they pull the gauge skin of the pack when placed in that vehicle? If I have people re-define their gauge textures as skins I can apply them dynamically rather than having them make a whole new set of JSONs for something that'll work fine with the current set. This wouldn't replace the ability to make new gauges, but it would cut down significantly on gauge duplication in the GUI, to the point a scrollbar wouldn't be required.

Implemented in V16.0.0.