Currently synced custom paremeters consume either 1 or 8 bits out of the 128 bit total available for each avatar. If I store my selectors as Ints, I feel like I have enough ideas per avatar to easily exceed this limit.

But some selectors don't necessarily require 8 bits of storage. For example, if I have 8 facial expressions, I could encode that information in only 3 bits. That means my Int parameter is wasting 5 bits, which could easily contain another selector or maybe a bunch of toggles. If I have at least 2 low count selectors in my avatar, I can kind of do this by having a single "Command" or "Macro" Int parameter for the menu to set, where each position represents an unrelated command, then encode everything else using Bools and drive the Bools with parameter drivers. But that's an unnecessarily cumbersome method and also breaks my ability to use Toggle controls in the menu (or, in other words, to display state).

The easiest solution for this problem would be for the SDK to provide shorter integers as synced parameter types for storage. At least 2 and 4 bit integers, although due to the size of radial menus I feel like 3 bits would be extremely useful too. In the playable layers, all of these would be translated into regular "ints", but truncated if their value exceeds their capacity when being synced or stored.

The idea in https://feedback.vrchat.com/avatar-30/p/feedback-control-the-not-sync-parameters-from-expressions-menu also mitigates this problem (though it's worse), since it would allow local variables in the menus to display state and integrate features in a more human-friendly manner. It would still require encoding into Bool parameters to be performed with parameter drivers, though.

Another great way to solve insufficient storage woes would be to give VRC+ users the ability to store 256 bits per avatar (as the uploader). Seems like the sort of thing people would actually pay for.