if i want to write a program to solve a given traveling salesman progam, i can write one that simply prints the output desired.
who's to say this is an invalid implementation?
i can't think of a clear line in between directly printing the intended result and 'computing' it. imagine your computation gets more and more simple and involves more and more hard-coded constants. at which point is it no longer a solver for that problem?
of course, the obvious counterargument is that the algorithm should be able to generalize to all traveling salesmen graphs. yet this can easily be done with a non-turing-complete computer. all the interpreter knows how to do is take the element from a very large array whose index is the input given. then precompute all values and include them in the "program." that you may or may not need a turing-complete computer to do this is irrelevant.
problem:
  if it's an *actual* turing machine, you need a "program" (very large array) if infinite size, because the size of input graphs it can take is unlimited.
solution 1:
  since universal turing machines can't be implemented anyway and are hence purely theoretical, i don't see the need to actually store this program; simply define it to be the infinite sequence of answers to all possible traveling salesmen graphs.
  but is it legal to define an infinitely long turing program?
solution 2:
  on an *actual* computer, even with a real programming language you couldn't solve every possible traveling salesmen graphs by virtue of its being an LBA; you don't have enough memory to store all possible graphs.
  thus both LBA's and my hypothetical array indexer can solve the traveling salesmen problem but olny up to a limit.
  thus LBA's, while interesting, aren't proven to be in a separate Turing class from my array indexer programming language. it means, basically, that they're not proven to be turing-complete. i think it's already accepted taht they're not turing-complete, but it's sort of assumed that they're a sort of middle-ground. this may be true, but not formally so - at least not until somebody invents/finds a formal distinction/proof.

yes, my argument only involves the traveling salseman problem, while turing-complete machines must be able to solve any problem that any other one can, not just the traveling salesman. but my argument is easily generalized to all possible problems: our array is now an array of solutions to all possible programs, and the program passed is an index. but that doesn't actually work, because of the halting problem. the array is undecidable.
solution 1:
  that's not necessarily true, because
    a) it's not known whether or not there is a way to determine a maximum possible number of steps a given program can take before it's necessarily non-halting. if there is, then it's decidable whether a program halts because it can be run up until the max number of steps. if it goes beyond that, it's non-halting. then our deciding function can retun a reserved value or symbol for that array location. just to be strict, if necessary we can define that our array indexer program sleeps indefinitely if it retrieves the non-halt token
    b) the halting problem relies on the fact that a program cannot determine if it itself halts. but this question is meaningless if the language does not specify a way for the program to refer to itself. the program cannot be passed to itself as a parameter as an alternative, because that requires passing itself as a program taking a parameter which is itself taking a parameter which is itself, ad infinitum. (but this goes back to the question of whether we can have an infinitely long program. and, in an LBA, we obviously can't.)
solution 2:
  insted being able to pass it programs in some known turing-complete language, just start with an empty look-up array and expand the array's definition to include any problems anyone trying to evaluate its turing completeness comes up with. so if he wants to be able to solve traveling salesmen problems, enemurate all possible traveling salesment problems to index their answers (which are decidable). prefix all traveling-salesman problems entered into the "program" with a type indicating that we're indexing a traveling salesman problem. but would we be able to enumerate all problems of multiple type of problems, while each type could have an infinite number of specific problems? i don't know enough about the diagonal argument to know that. i suppose we could, as long as our number of types of problems is finite. otherwise we might have trouble. but does it *have* to be defined as infinite?

any programming language in which memory locations store arbitrarily large integers, such as SUBLEQ, isn't necessarily turing-complete; they could be LBAs.

these algorithms are in practice implemented on LBA computers. to prove they're UTM's one would need to be implemented without an upper bound on a genuine UTM's.
you can't just take a theoretical von neumann machine with infinite memory to emulate SUBLEQ on, because accessing a single memory location on such a machine involves an infinite regress: even if your addresses themselves were stored as BIGNUMs, you need a way to read and write individual bits/bytes of the BIGNUM. If your BIGNUM array indexes have a specified bit-depth, your BIGNUM size is limited, and hence so is your address space. If your BIGNUM array indexes are unlimited, they need to be BIGNUMs themselves, which themselves must have BIGNUM array indexes, ad infinitum.
a von neumann machine with infinite size probably isn't a self-consistent proposition until it can be proven to be emulatable by a bona fide UTM.
the crux of the problem here might be that if you have an unlimited sequence of memory locations and each one can hold an unlimited sequence of data itself, you're now in uncountability-space, and g/l running algorithms on a machine that *depends on* the axiom of choice.