I changed the functions'/variables' names as you suggested.

As for the command in my opinion it's a bit clearer to reading/using the code with 2 separated commands, instead of taking care of the various bits. Like if bit 1 is set, then bit xyz is this, otherwise unused; if bit 1 not set, then bit abc is that, otherwise unused, and to shift bits back and forth.

There are 4 things in this PR:

• Collapse/expand: (1st commit)
  • I like the feature and the implementation.
  • At some point someone should draw nicer icons, but considering how difficult it is to add icons and rebasing branches with them, this is for "after merge".
• Create a new group by dragging the vehicle on the "new group" button. (half of 2nd commit)
  • There is already a similar feature: You can drag the vehicle onto an empty row.
  • Funnily this seems to be broken for a long time: once you get scroll bars, the list does not show any empty row anymore.
  • I kind of prefer the "empty row" approach, but I guess it does not hurt to have both.
• Automatic naming of groups: (other half of 2nd commit)
  • The implementation of this has many problems:
    • A client setting and GetString() is used in command context, so this won't work in multiplayer.
    • Every client including the server will use their local client setting, and their local language for translations.
    • When joining a game, you will get the groups with the names from the server.
    • Increasing the length limit of names probably exceeds the limit for command packets. (did not check this).
  • However, independent of the implementation: I think this feature no longer makes any sense.
    • Feature: Option to group vehicle list by shared orders #7028 made it unnecessary to have groups per order list.
• Automatic splitting of vehicles into groups by shared orders. (3rd commit)
  • Same, obsolete with Feature: Option to group vehicle list by shared orders #7028.

So, as merge candidate:

• Collapse/expand: yes
• Create new group by dragging on "new button": most likely
• Naming of groups by orders: definitely no
• Splitting into groups by orders: probably not

* Automatic naming of groups: (other half of 2nd commit)
  
  * The implementation of this has many problems:
    
    * A client setting and GetString() is used in command context, so this won't work in multiplayer.
    * Every client including the server will use their local client setting, and their local language for translations.

Because is this causing desync or just looks "weird" when you compare the group list between the clients?

    * When joining a game, you will get the groups with the names from the server.

If you join to an existing company, you can easily recreate all of the groups. Just press the delete all groups button, than the create groups automatically button.
I play in single player mode, but I think it almost doesn't matter what the groups of other companies are called in multi player mode.

Anyway I see that it isn't "nice". But maybe could be there a place holder SCC_XXX code or something in the group names, and the clients could substitute them when the window is drawn. Or always get the group names from the server.

Or as easy alternative:

• In multi player mode, the groups would be created without the cargo parent groups, and named by only: Town A - Town B #N. Its not that nice, but better than nothing.
• Just hide the auto create button in multi player mode. Its a pity for the multi player guys, but single players could benefit from that.

I know these are just workarounds, but I do think this is a useful feature. I never liked manually type in the group names.

    * Increasing the length limit of names probably exceeds the limit for command packets. (did not check this).
  * However, independent of the implementation: I think this feature no longer makes any sense.
    
    * #7028 made it unnecessary to have groups per order list.

I do not agree. I do not find #7028 too useful.
For example, you have 6 identical trains: A weak initial locomotive + 5 small coal wagons. You have 2 routes. On Route 1 you have 2 trains, on Route 2 you have 4.
As time goes on, you have to replace your locomotives for some reason. On Route 1 you want a new weak locomotive and existing wagons, because they are enough. But on Route 2 you want new large coal wagons, because the mine's production has doubled during the years. But for the new wagons, you need a more powerful engine. How can #7028 help you to replace your vehicles easily?
So I think it is still necessary to have groups per order list. #7028 does not changed nothing in the case of this matter.

#7028 can be useful if you start the game in 2050 and you just use the same engine everywhere, and you have only 1 wagon to carry a specific cargo. For example a game without NewGRFs. In that case you do not have to replace your vehicles, the autorenew feature solves it.

* Automatic splitting of vehicles into groups by shared orders. (3rd commit)
  
  * Same, obsolete with #7028.

See above.

This PR has potential but hasn't been touched in two years. I think part of the problem is that it's trying to do too much.

I'm going to close this but encourage you to separate each feature and open a new PR for each one. That would be much easier to review and evaluate than having them all together like this (for example, the Preview feature is great but it's hard to track down which feature comes from which commit).

I'd like to see some of these features in the game, just help us by making them easier to review. 😃