GSX already has this capability internally, as can be seen on some FSDT airports that have smarter grouping, like KORD, KSDF and KCLT.
However, it's made in a purely programming way, with actual Python data structures and string creation rules and subroutines, like a piece of code.
This make it very difficult to adapt it to an user interface, especially considering that, when altering names and grouping, the Airport configuration page should immediately redraw the whole Tree structure to reflect any change to the structure.
To give you an idea how complex and powerful the internal system is, which translates into how complex would be making it "visual", here's how a couple of lines for the KORD custom profile ( that is actual Python code located in GSX\airports\kord_v2_fsdt_MSFS.py )
__T1_C_GateNames = CustomizedName("Terminal 1, Concourse C|Gate C#", 1)
parkings = {
GATE_C : {
None : ( __T1_C_GateNames, ApproachLengthAndWidth(70, 10),),
},
}
The first line has defined a variable pointing to a function, which accept a text "rule" as a parameter, which can be expanded to group the gates using that function in the "Terminal 1, Concourse C" GROUP, then the | "pipe" sign is a delimiter to indicate the next part of the string is the rule to define how to display individual parking spots, in this case like "Gate C1", "Gate C2", "Gate C3", due to the expansion of the # character into the actual gate number, taken by the scenery.
The second line uses a Python data structure ( a Dictionary ), which represent all parking spots in the scenery, and the Dictionary contains a variable number of Dictionaries ( so they are nested ), I only shown the ones for GATE_C, but of course we have one for each gate group in the scenery so here, we say that all gates that were originally named as GATE_C in the .BGL (or the Navdata, it's the same), would use the __T1_C_GateNames object defined earlier. And the "None" at start, indicates we don't care which number the parking has. The ApproachLengthAndWidth indicates a custom size for the "corridor" in which the VGDS detects the airplane, since it might be bigger or smaller depending on the airport.
But we could have made something like this too:
parkings = {
GATE_C : {
None : ( __T1_C_GateNames, ApproachLengthAndWidth(70, 10),),
23: ( CustomizedName("Terminal 1, Concourse C|I am Gate C23, and I don't use the default rule", 1) ,),
24: ( CustomizedName("Terminal 1, Orphan Gate|I am Gate C24, and I don't know which concourse I belong to", 1) ,),
},
}
Meaning, most of the parking spots on GATE_C would normally use the same group and show the gates named in a standard way, but 23 and 24 are presented differently, 23 with just a different name, and 24 even outside the group.
This would affect BOTH what you'll see in the GSX menu when using the scenery, but also the editor "tree" structure itself. I hope you understand how tricky would be translating this purely programming structure into something visual, since even the smallest change would require a complete redraw of the customization dialog.
We are CONSIDERING adding the ability for users to JUST code in Python, not just for this function, but also for other things like a deeper airplane configuration. But it's more like a mid-term project, something we need to do it properly, possibly with some kind of integrated text editor and possibly a debugger, so it's not a quick fix, more like an foreseeable evolution, to allow users to work on something GSX already can do internally, but it's not fully exposed, because it was only meant for us.
