The Loop and Variable blocks could always run any query WordPress can run. You just had to write the args by hand: the right post_type, posts_per_page, orderby, order, remembering that terms filter through a nested tax_query and not a plain category. Fine once you know it. The knowing is the wall.
This beta adds a Visual tab next to Code on the query panel. Same query, none of the typing.
Three vocabularies, not one
You pick what you’re querying first, posts, terms, or users, and the builder shows only the fields that type actually understands. Posts think in post_type and tax_query; terms in taxonomy and hide_empty; users in roles and capabilities. Flattening those into one generic form would fit none of them, so each gets its own. The common fields sit out in the open, and Add argument opens a searchable panel for the rest. Something even that doesn’t list, a rare third-party query var? Drop in a custom argument.
And the fields know what they hold: a post-type field lists your registered types, an author field searches your users. Order by a custom field and the meta key field it needs appears on its own. You’re choosing from what fits instead of trying to remember it.
The filters are the point
Simple queries were never the hard part. The pain lives in meta_query and tax_query, those nested arrays of relations and operators where one misplaced key breaks everything silently. The builder hands you the same AND / OR group tree from the Condition Builder, and writes the native WordPress array underneath. Comparisons read in plain English, and the value field follows along: a range asks for two values, an existence check asks for none.
No layer in the middle
You’ve heard this part before, because it’s the whole plan. Visual mode is just a view of what Code mode shows. Build by clicking or type it by hand, either edits what the other made, and any value goes dynamic through the same Data Picker, so author__in can resolve to the current author instead of a fixed ID.
What runs at the end is a plain WP_Query, WP_Term_Query, or WP_User_Query, passed through untouched. Every WordPress arg works, present and future, whether or not the builder drew a field for it. Approachable by default, open whenever you need it.