Hi, Phillip. Thanks for the response, and for taking on these issues. I also sent a more detailed direct report to frontdesk@torproject.org. It apparently crossed with your reply to this thread in the mail, I wasn't intending to nag. I assume that'll end up forwarded to you as well, hopefully the extra detail I was able to include there will be helpful in debugging the problems.
I think the hash ring allocation question may be the most severe and fundamental issue overall. The BridgeDB request page still just now insisted to me yet again that there are no vanilla bridges available at all. Even if plain vanilla ORport bridges are no longer the majority, there must be at least a few dozen (if not a few hundred) remaining, more than enough to ensure at least a few end up in every hash ring. I'd never expect to be told that there are no vanilla bridges available, period, but that's the only result I've gotten over many tries for a few days now. Only getting back 1 or 2 obfs4 choices, which often show up again well past the selection rotation interval, also seems like it points to not filling the hash rings properly. Or maybe something broke in the result filtering stage where it removes supposedly blocked or same-subnet choices? Even if a lot of the obfs4 bridges are unreachable, they should still be showing up in the response lists, and for some reason they aren't.
Anyway, thanks again, and if there's anything I can do to help test things feel free to email me directly.