GOTO as a keyword doesn't need to be provided for GOTO as functionality to exist.

No, that's certainly true. All you need is something that is substitutable for GOTO. This may be a single feature that by itself is isomorphic to GOTO (which can range from the obvious (JMP) to the slightly less obvious (COME FROM), or it may be a set of features that can be grouped together to accomplish the things that GOTO can also be used (in combination with its helper instructions) to accomplish. The latter kind of isomorphism is more interesting, because there is no direct counterpart for GOTO per se, but its functionality is covered anyway. In this case, the mapping is at a higher level than the individual instruction.

Whenever you call a subroutine, some form of GOTO activity occurs.

This is generally true, though in theory it would not necessarily have to be. Most CPU instruction sets are designed with a certain traditional set of instructions, usually including near and far (or relative and absolute) unconditional jumps, and so computer languages compiled to those processors of course boil down to using GOTO for stuff. It seems to be easiest for the lowlevel programmers who implement microcode and assembly languages to think this way, either because it's what they were trained in and know, or perhaps for some other, more inherent reason. But having played around just a little with electronic circuits (oscillators and things) I can imagine other possible ways for things to be. It would be possible, for example, to manipulate control by turning various gates on and off. Some other operations would be needed for Turing equivalence, but for that matter GOTO by itself doesn't cut it either.

All subroutine calls (which is Unlambda) are performed by GOTO-type functionality.

You could as well say that all hash lookups in Perl are performed by GOTO-type functionality, since I'm sure a jump instruction gets executed by the CPU at some point duing the process. As far as I can understand the way Unlambda does things (which, admittedly, is limited), there is no subroutine calling per se, as far as I can determine; there are subroutine combinators and subroutine application, but I'm not at all sure that either of them by itself is directly analagous to a subroutine call, though my understanding of the language is limited. However, they add up to being able to do the same things that can be done with other paradigms, such as subroutine definition and calling. (Incidentally, I'm fairly sure that Unlambda has nothing directly analagous to subroutine definition in the usual sense, which is part of the reason I suspect it doesn't have an analogue for calling either, since the two normally go hand in hand. If you know otherwise, I'd be interested in an explanation of how this works, as I've been reading up on Scheme and as a result am becomming intrigued somewhat by Unlambda. As near as I can determine, Unlambda functions are as much like data as like code.)

$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,".rekcah lreP rehtona tsuJ";$\=$ ;->();print$/
[download]