I get where the ‘target’ comes from. Proximity also uses ‘target’. Still, in combination with the words ‘transfer’ and ‘source postion’ it is quite confusing.
maybe just renaming ‘source position’ to ‘sample points’ or something like that would be enough…?
The word “target” IMHO is very inaccurate, I understand why was it choosen, but the target in general is “where I’m going to apply the result of this”, and in this case is more “from where am I getting the information to get a result”, so I would change that name to “Source” more than “target”.
Just my 2 cents on this thing 
I don’t mean that Blender handles these cases ambiguously. There is a grammar to GN, and given sufficient understanding of that grammar, you can parse these. What I mean is that, if you hand those pics to somebody with imperfect knowledge of GN and ask them to evaluate them, without having Blender to test them, you’re going to get more people answering, “I don’t know” than you would with 2.93 field-less equivalents.
I’m curious about the second one. It makes sense that, given what you’ve said, that the transfer attribute is part of a field (function) that is called by Group Output. But in that case, how can I specify that I want the transfer to act on pre-scaled geometry, without using multiple GNs? Anything I do to “close the brackets” on the function and link it back to the main geometry chain will do nothing to close the brackets for the noodle leading to the output. Any link will just mean that two different transfers are happening, with the output of one discarded. Perhaps this is just not possible until we have arbitrary get/sets so that I can realize the data transfer on the geo and then output something from the geo?
The source/target terminology for Transfer Attribute makes perfect sense to me, because it acts exactly like a Data Transfer modifier, where those same terms refer to the same entities. The only thing that strikes me as weird about the naming is that it’s not called Data Transfer to take advantage of users’ existing knowledge.
Ha! I’m new(ish) to blender. And only after pulling my hair out for an hour in figuring out the the fields Attribute transfer node I finally understood the Data Transfer modifier for the first time as well. I’d say it’s confusing as hell over there as well. 
Though I get where it comes from, with all modifiers always using ‘target’ for a selectable object.
The function is not called by the group output. It’s called when it is being connected to a data flow node.
This, for example, the Position here Is an empty shell referring to something called position but it is actually not the position data, so just imagine it as an unknown variable x. so f(x) or f(position) = position + (1, 1, 1), and without the specific value to “substitute” the “x”, this function would not yield anything.
Of course the node tree eventually needs to be connected to the group output in order for the node tree to run but the function in particular is not called by the group output
In the transfer node’s case, I am not sure but I believe it works like this:
Here’s another good example. This one is nice because it’s not artificial; it’s something people would actually want to do with geo nodes:
This is something that should probably have been built into Blender a long time ago; it lets you just make a new sub-bone, paint that bone unnormalized, and then steal weights only from its parent bone, so that you don’t affect any of your other weights. It’s possible to do with multiple vertex weight mix modifiers, but doing it like that is way too much work to set up, so instead, weight painters just don’t do this in Blender-- the complexity ceiling is too high. GN promises to simplify it, and indeed, it’s trivial to do in 2.93.6. So this is a very real-world problem.
Assign all verts at 1.0 to StealFrom and StealTo, then apply the geonodes. Expected: StealFrom 0, StealTo 1.0. Actual: StealFrom 0, StealTo 0.
Hmm, that’s interesting. What if we swap to StealFrom and StealTo noodles? I mean, there’s nothing that the noodles imply about evaluation order, but as somebody that’s poked a lot of things, that seems like a good place to start poking. Actual: StealFrom 1.0, StealTo 0.0. That might work if we rename our outputs, for StealTo 1.0, StealFrom 0.0!
Let’s try another test case, StealFrom 0.5, StealTo 1.0. Expected: StealFrom 0.0, StealTo 0.5. Actual: StealFrom 0.25, StealTo 0.5. Sigh, I guess it doesn’t work.
This is another case where personally, I just don’t see how this simple operation can be done without using two different geonodes modifiers. And like I said, this is as real-world as it gets.
@vasiln That’s actually just a bug. It would be nice if you could report it on developer.blender.org.
What happens is that first the StealTo output is computed, and then the StealFrom output. But when computing StealFrom, it uses the new StealTo value.
We already have some infrastructure to handle such cases correctly, but didn’t use it properly in the modifier code.
I’m not entirely sure what you mean, but it sounds very much like what the Capture Attribute node is supposed to do.
Thanks, capture attribute indeed is what I’m looking for; I didn’t quite understand how to use it earlier. It can also be used as a workaround for the last problem I demonstrated. I made a bug report at ⚓ T93715 Geometry nodes output depends on order of outputs and @'d you there.
