To further explain "anything more reasonnable" as I see it, three options:

1. Good

Add to list=allusers new property auindefblocked. If set then that user is indefblocked irrespectively how: straight in that subproject, by a steward, by am emergency midnight Foundation meeting, anything else.

2. Greate

To make the property blockinfo reflect any type of (b)lock info, local or global.

3. Fantastic

All as (2) plus introduce new virtual group indefblocked so could be used with auexcludegroup. This way queries will not report thousands and thousands useless items to filter out client-side.

Which "blockinfo" are you talking about?

• Various error messages report blockinfo when some action is prevented due to a block. It would be up to User::getBlock() to return something appropriate.
• meta=userinfo does basically the same.
• list=allusers and list=users report only block info for local blocks, as these are the only ones that can be efficiently queried in bulk.
• list=blocks similarly reports only local blocks.

I guess from your examples that you're talking about the third bullet.

In T207500#4683367, @Neolexx wrote:

1. Add to list=allusers new property auindefblocked. If set then that user is indefblocked irrespectively how: straight in that subproject, by a steward, by am emergency midnight Foundation meeting, anything else.

There would be no point to that. If we could do that efficiently, we'd most likely already be doing #2.

2. To make the property blockinfo reflect any type of (b)lock info, local or global.

For list=allusers and list=users, doing this would require some mechanism for making such queries efficiently in bulk. We don't want to be doing 500 single-user queries for each extension that implements global blocking of some sort.

3. All as (2) plus introduce new virtual group indefblocked so could be used with auexcludegroup. This way queries will not report thousands and thousands useless items to filter out client-side.

Since virtual groups can't be used with auexcludegroup in the first place (only groups that are tracked in the user_groups table), that's not going to be possible either.