That said, at the time you had no issues with me forking dasm-tigcc

Yes, and you misunderstood my message...
IIRC, at the time, Thomas had already agreed to the principle of relicensing the code (his own, of course, not the rest of the strange mix) under a GPL-compatible license, which allows forking. I didn't have any, and I still don't have any issue with you forking dasm-tigcc, because I can't have any.
So that's not what I was trying to point out, it was obvious to me. What I was trying to point out is that dasm-tigcc is a(n improved) fork of ttdasm, and that to me, integration into GCC4TI would be integration back into upstream (which you disagree with, it's your right).

and even refused to integrate it into the TIGCC Tools Suite on the grounds that it pulls in too much stuff.

I don't remember writing that it pulls "too much" stuff, much less where, but if you say I did, I must have done it... However:

Funny how your opinion changes.

... my mind hasn't changed that much on pulling stuff: as shown in this topic, I'm still worried by external code being pulled (and for some bits, forked, as you wrote), because of the possibility to forget backporting fixes from upstream.
I've already changed my mind on a number of topics and persons since I've been in the TI-68k community, but this one is not one of them.

Then you should make that the default, not build dozens of versions of ttstart which only confuse people.
But it leaves users confused about which version to use. Regular users should get one default version, advanced users can recompile.

Did I write that we were going to provide all 12 or 24 (forgot one earlier today) versions of ttstart to final users ?
No, I didn't. Did you seriously think that we were going to do such a blunder (it's obvious that providing that many executables would confuse users) ??

Then you build a version which supports them all. So you have 2 TPRs, ttstart and ttstart-all. How's that not enough?

Well, prove us that reducing from 12 or 24 to 2 tests will not lower the quality of testing (which is not even a metric of correctness, as you know)
As I wrote above (./11, "(I guess that the testing work can be narrowed a bit down from 11, or 23, executables, but that's still some testing work). "), I didn't seriously think about testing all combinations. For example, since the ASM support is mostly independent from the test, only two executables (one or even two of which can be used in other tests as well) need to be tested for checking ASM support:
* ASM support disabled: check that it cannot launch an ASM program;
* ASM support enabled: check that it can find and launch an ASM program;

Does TIEmu have an easy way to get the data output through the link port (like, say, VTI Logger) ? That could enable automated tests of launchers (and other programs), through the use of ROM_CALL_479 "link_printf"...

1. decide on where to put it in CVS

TIGCC module, doc/Programs ?