Looks like we've had the same idea
I'm currently working on it, but I silently did so until this post, because:

So theoretically, all I would have to do to make this run on a 68k is write some platform-specific routines for the 89 and get it to compile using GCC4TI.

(emphasis mine) Getting p14p to compile on GCC4TI is the main problem. p14p requires improvements in both the toolchain and the library, to make them somewhat less non-standard and more flexible. And even then, some wrestling with the toolchain's peculiarities, in the Makefile, is required...

I do have a partial (without UART support, so no interactive module) port in perfectly working shape, it can do significantly more than print("Hello World !"). But it can't be easily released before the next beta of GCC4TI, because of the toolchain and library changes, and the fact that compiling GCC4TI from SVN isn't easier than compiling TIGCC from CVS...
In GCC4TI, we've worked on the user scripts (aborting upon error instead of silently finishing incomplete builds, large portability improvements, etc.) but not much on the maintainer scripts. In the longer term (i.e. not a target for the next GCC4TI beta), that set of ad-hoc build scripts inherited from TIGCC ought to be replaced with something better...


While I'm at it: I'm also working on the "kernel"-based Lua port for the 89 I recently found about in a discussion on yAronet, and linked in another topic on Omnimaga. I've cleaned up the patch, it will need forward-porting from the old Lua 5.0.2 to newer versions.
I need to make conditional the reimplementation of strtod contained in the original patch: I recently added strtod to GCC4TI (I knew since 2002 or 2003 that AMS contained a strtod, and I notified the TIGCC maintainers, but nothing happened...), but I'm not sure that PedroM has it at all, or has it wired on ROM_CALL_4D4.

This is a great idea, I've always wanted on-calc Python, I hope you can make it succeed

EDIT: I now read the whole topic and see it's impossible, but I hope that eventually it will work

I have no precise ETA for the next beta of GCC4TI... Most of the things I'd have wanted to do for the next release have been done, but the server (Trac, SVN) has been used in read-only mode for months, after a hard drive problem, and godzil (owner of the server) doesn't have much free time.
Over the months, I've pushed a number of patches to https://github.com/debrouxl/gcc4ti (it's linked in the topic line of #GCC4TI, but not on the GCC4TI wiki, for the aforementioned reason). I need to push out several more patches I performed in the last few days - after more testing on some of them (strtod, snprintf, vsnprintf, etc.).
snprintf and vsnprintf haven't crashed on me in p14p, and they return the correct number of characters (because p14p does not print either truncated messages, or the ending 0x00) - but I haven't tested them in corner cases, e.g. length = 0, or aborting when vcbprintf would like to write more characters than the user has specified

Making a source tarball packing all those changes together would be rather easy - but it wouldn't help Windows users, who represent the majority of the user base. Windows users need a recompilation of the existing, modified tools, and a compilation of the new tools.


BTW, my motivation for the small-scale side projects of porting p14p to the TI-68k platform, and fiddling with the Lua port I recently found about, is an exercise in testing the non-standard toolchain and library against a wider range of real-world programs, and improving several bits as a result.
If you will, "I know fully well that the standards compliance of GCC4TILIB and GCC4TI is mild (though it's higher than that of TIGCC) - but how bad exactly is it for select real-world third-party programs, and is it easy to improve ?". I don't even speak Python or Lua

To me (others are free to disagree ), it's not an exercise in providing programs that would eventually prove highly useful to users:
* the TI-68k platform has always been much less widespread than the TI-Z80 platform, because its CAS forbade its usage in a number of standardized tests, and it was abandoned by TI six years ago;
* the TI-68k user and programmer base has been quite small for more than three years;
* most of all, there are better tools for programming TI-68k calculators in relatively fast high-level languages, starting with Newprog

In my tests, p14p and Lua89 have proved to be fairly slow:
* p14p: recursive Fibonacci with parameter 12 takes hundreds of milliseconds;
* startup time of Lua89 (5.0.2) is 2-3 seconds.

And it's pretty natural, I somewhat expected such kind of figures: the TI-68k platform is < 3 MIPS (12 MHz clock, all instructions take 4 clock cycles or more).
Lua is quite a good language for embedded platforms in general, but the only reason Lua is tolerable on the Nspire platform is that it's a > 100 MIPS platform (CPU can be clocked at more than 200 MHz, and instructions on ARM processors usually take 1 or 2 clock cycles).
Straight MIPS figure comparison isn't accurate (when dealing with memory, ARM often needs at least three instructions where the 68000 often needs one; this ARM flavour used in the Nspire doesn't have integer division), but the Nspire platform is, more or less, an order of magnitude faster than the TI-68k platform

One last note: the roadblocks in porting p14p, Lua or other similar real-world programs to the Nspire/Phoenix/Ndless platform are likely to be more in the library than in the toolchain itself (which is stock, unpatched GCC+binutils).

EDIT July 10th: publishing the patch, which I refreshed today but hasn't changed since July 2nd: http://www.mirari.fr/V6V4

Indeed, that's much better than TI-BASIC, which I didn't even try to test
But it's still too slow for serious computations and for Lua on the TI-68k platform becoming more than a proof of concept...