Any value of PriorityAsStringOrder which was different from the computed set (by re-ordering or substraction of levels) would also cause the levels for display to be incorrect. Fix the algorithm to be independent of the PriorityAsStringOrder setting, and update the documentation to make it clearer that most use cases do not require setting it.
RT::Config->Get uses the Type of the configuration entry, as determined from its META hash, to decide what to return in array contexts. Additionally, RT::Config->Set explcitly alters the same Type based on how it is called. Thus for array values, in the absence of an explicit Type, the ->Get method returns (undef) if it has never been ->Set, and a (possibly empty) list otherwise. This leads to ->Get being extremely unreliable in hash contexts. Explicitly set the Types of the three configuration variables used in the extension. This allows them to be reliably passed to ->Get in list context, which simplifies their access considerably. Notably, for instance, the PriorityAsStringOrder variable no longer needs to filter out undefined values, as were previously encountered if it had never been ->Set.
Move /Elements/SelectPriority to /Elements/SelectPriorityAsString so we can preserve the old behavior at times, and choose when to force the dropdown. Leaving @PriorityAsStringQueues empty preserves the old behavior; as soon as it is non-empty, each call site examines their queue and calls the appropriate component.