You can think of an inputset (named or .) as some kind of global variable, which is valid for the whole query. Once you assign some data to it, it will keep it for the rest of the query. If you assign some other data to an inputset, the previous contents will be replaced. Note that some queries / statements will change the contents of the default inputset ".", which can be confusing at times. If you’re unsure, use named inputsets instead, like in my example.
If it’s not mentioned in the Overpass QL documentation there’s probably no dedicated document. Usually you would find the respective information for each statement, like union, or foreach.
Yes, that’s due to the way how ways are resolved to nodes. The approach I used is more suitable for editing in JOSM, as it includes all data (out meta; instead of out; would still be better). If you don’t want to this level of detail, you could use either http://overpass-turbo.eu/s/q0a or http://overpass-turbo.eu/s/q0f
Well, that was my intuition at the beginning (one of things I tried before posting here was switching to .nodeless set instead of ._).
OK, so just to see if I understand it correctly, I’ve changed the original query to: http://overpass-turbo.eu/s/q42
It uses named set .nodeless instead of ._ , does not initiate .result set and tries to collect buildings directly into .result inside foreach loop. Could you pinpoint why this query does not return any buildings? I know your query is better, but I want to understand what I’m doing.
foreach iterates over all entries in the default set ._. At this time it contains a number residential ways, which is in fact a side effect of an earlier way"highway"=“residential”; inside a union statement.
Now, (.nodeless;) → .a; is basically just copying ALL residential ways from .nodeless to .a - that’s not really what you want, especially, as the copying occurs in every single foreach iteration. What you’re really after is to take one element from .nodeless and store it in .a.