I love this proposal idea!
I think the main two concerns so far are source breaking aspect (@jrose) and the risk of exposing the ResultBuilder implementation details accidentally; I think @codename's suggestion of a nested Namespace type, + this below, would be a nice and elegant way to solve both concerns at once:
i.e. if the ResultBuilder doesn't have a Namespace nested type (or typealias) then there won't be any unqualified lookup and it would still behave as current Swift's behavior; but if there is one, it would opt-in for the unqualified lookup behavior pitched in this proposal. 
The only source-breaking aspect left with this solution is if someone have created a custom ResultBuilder which already had a Namespace nested type today. That would be way more unlikely though compared to without that rule/condition about Namespace nested type existence, so I personally think this would be acceptable.
If we really want to prevent source breakage risk completely, we could also imagine a parameter to the attribute, eg:
@resultBuilderwould behave as today's Swift@resultBuilder(MyNamespace)would opt-in to the new pitched behavior and declare the name of the nested type to use for unqualified lookup.