I'm saying I don't think bare function names should be allowed in key paths, yes. I do think they should probably also be disallowed in member expressions, but that's not currently under discussion.
In theory, the same ambiguity and source evolution problems could arise with bare identifiers, but it seems to not happen in practice. You can't have a conflict if the name resolves locally (at least, not a surprising one), so it would have to resolve globally (or be an implicit member reference, which I would bundle into the rule above), and that's unlikely to conflict because, in my experience, Swift programmers tend to avoid global-scope variables and functions in the first place. Operators are the main exception, and they don't conflict because they can't be easily used as variable names and tend to have fixed arity.