Currently e.g. input/output module options seem to be alpha-sorted by PV in the respective dialogs. The same probably applies to other areas, like PD options, channel names, whatever (haven't checked, though).
IMHO this should not be sorted by the frontends, but rather the extact driver/module/PD ordering should be used in the UI dialogs.
That allows the driver/module/PD authors to pick a "useful" ordering that makes most sense for the specific driver/module/PD or use-case, which rarely will be the alpha-sorted one. Even if that were the case, the author can make it alpha-sorted in the driver/module/PD then.
Example: Some options might depend on each other, or be related somehow, and the author can use that and sort them in a way that makes sense (e.g. more important ones at the top, more optional ones lower; or group related ones together, etc).
There is no sorting, however the C++ bindings (and also PV internally) use the std::map type to store the format options:
map<string, shared_ptr<Option>> InputFormat::options()
map<string, shared_ptr<Option>> OutputFormat::options()
maps store their entries in random order, so iterating over their contents to create the UI elements yields unpredictable results.
Fixing this bug requires a C++ binding API change, so postponed to the next libsigrok release.