I'm not sure if the FILE_ATTRIBUTE_ENCRYPTED bitwise constant (displayed 'E' in x2) can be electively set by the user or not (I shall do some experiments), and even if it can be, I am unsure of any odd "side effects" which may incur given that the Windows shell has its own mechanism for colour-coding those particular items, and indeed may handle them as spooky Masonic artefacts without consenting the user first. Thus, "the jury is out" on that one, unless other users have more experience than I.
That said, the one elective attribute
which you can set manually and which qualifies as a colour-rule is FILE_ATTRIBUTE_OFFLINE which x2 displays as 'O', so a rule which looks for 'O' in Attributes [S] could be applied. There are also those amongst us who consider the archive-attribute 'A' to be mostly superfluous and available for user misdirection... but since it's so common for 3rd-party backup programmes to arbitrarily play with that themselves, long-term reliability can only be discerned from experience.
Other attributes may also be set (as above), however x2 won't display them so they are relatively useless in this context. (Curiously, there are even some unassigned bits in the Windows API bit-enumerations which can be used for bespoke ends themselves [0x00100000 and 0x00200000], but again, x2 is oblivious to these, so I mention them more as amusement than detail.)
Overall, keep in mind that just because x2 colour-coding rules can't be stacked, that doesn't mean that they can't be
abused.
For example, you are free to create duplicates of all (or at least your most important) rules - one for normal files, and one that includes (for example) the condition for a drive-letter or path node, etc. I do this for many of my rules where I use a certain colour for "hidden" folders, and yet I also like to have all folders display in bold-face. Thus, by placing the attribute check for "hidden" above the rule for ordinary folders, I can have bold-faced folders (always) with conditional colouring added. Granted, this exercise can get complicated if you start adding things for reparse-folder objects which may be in multiple-states, etc, but you get the idea - messing with rule-precedence can be its own workaround.
I use disc-image backups all the time, and when they are mounted-to-browse I too would prefer to be able to assign a proper background colour to the pane... however, as you have seen, mounted virtual folders are not so simple to distinguish within windows, even on the shell-level (in case you're interested, it gets even messier where USB drives which were once-plugged in, yet are now unplugged,
may still be seen within the drive-table as detritus while the letter occupied is itself currently reassigned to a virtual-drive).
Unfortunately, I don't know of a way to declare virtual drives as "special" in such a way as x2 may find them amorously arousing.
All that being said, I would lobby Nikos for a one-off rule-group which could be defined by the user as a trigger for pane-colour (in the same way as archives are now, just user-defined). That he would listen, of course, is another matter altogether... historically, his
ex cathedra pronunciations have not always adhered to my whims as closely as one may have preferred. Yet in spite of this, we muddle-on with the greater war at large.
).
)