That seems reasonable.
My understanding was the current use case was as you note:
and to do so independently of the RC configuration/preferences.
Agreed. Although my use case is subtly different: The Attribute X may be adequate for Property Y, but inadequate for Property Z. That is on me - I did weakly cast this as being validator specific, but it needn’t be. What is generic is the presence of more than one RC.
I’m not disputing the RC development pace, and the use case is more strategic than tactical. But, as I acknowledged, this use case is a non-speculative token and that is categorically different from DOT.
So far, as best I can tell, the differences fall within the scope of parameter settings. Apologies for not being clearer, the RC code base is working its way up my todo list.
This should focus things: Are there integration (or unit) tests exercising the multi-RC use case? Or even documented rules-of-thumb about the trade-offs?
Here you mean non-BEEFY bridges? Or does BEEFY share these properties?
I’m inclined to agree with your GH comment that OmniLedger probably has some useful insights/results.