As for the rest of your message:

Lionel Debroux (./11) :
As I wrote in ./4, I'm not merging pstarter.s and ttstart.s, only (if possible, I don't know yet for sure) the tts-* and pst-* headers. Again, reducing code duplication and easing maintenance.

Well, that may well be possible, we'll see.

It's yet another of my (emphasis mine) projects you're forking...

No. Rather, we're de-forking your (improved, it's a fact !) fork of one of the projects we're maintaining: besides having the same switches as ttdasm, dasm-tigcc uses some code from ttdasm. Fact, acknowledged in the copyrights.
What you're calling a fork of dasm-tigcc (if any: the command-line compatibility between dasm-tigcc and ttdasm would make it possible to make the new ttdasm just start dasm-tigcc...) is actually reintegration to upstream by the upstream maintainers
I don't remember dasm-tigcc being contributed to the former TIGCC Tools Suite, and I can't find a mail whose body contains "dasm" in my whole inbox (which contains mails since the end of 2005, i.e. before dasm-tigcc existed).Yes, "we" and a plural for "maintainer": by me importing the "GCC4TI Tools" -> "TI-68k Developer Utilities" into GCC4TI, the list of upstream maintainers has expanded. And unlike your fork, the upstream ttdasm will be maintained in a public SCM repository, not in a closed fashion somewhere on your own computer...

You're re-forking my fork.
That said, at the time you had no issues with me forking dasm-tigcc and even refused to integrate it into the TIGCC Tools Suite on the grounds that it pulls in too much stuff. Funny how your opinion changes.
At this point I'm no longer interested in getting it merged, if you want to do it now, you're on your own. And we'll probably end up with 2 separate versions given that you want to do changes I don't agree with.

Now, it's a fact that we're going to fork dasm-tigcc. Blame yourself for this, not us: we wouldn't have to fork dasm-tigcc if you developed it in cooperation with both your users and other developers
As you remember, the dasm-tigcc patch I sent you on 20080525 (before we decided to create GCC4TI) that I mentioned in ./8, was a PoC patch for an alternative, default-disabled, '%'-less syntax. Being trivial, the patch makes it clear how easy it is to program a multi-year-old (and multi-person) tiemu-gdb feature request.And what happened ? You dismissed the patch outright in a one-liner e-mail that read (in French) that it had zero usefulness...

Which is still true. The idea is to generate code which can be assembled with GNU as, Thomas intentionally changed it for that. So why generate code which doesn't assemble with GNU as's default settings?

In addition, your patch is simplistic, you're only dropping the '%' signs. What people asked for in the tiemu-gdb feature request was to support the obsolete A68k syntax (or the obsolete VTI syntax, which is very similar) entirely. This means $ instead of 0x, * instead of . for the current %pc and so on.

IMHO, TIGCC's tools should all use the same syntax (and I still think tiemu-nogdb should be fixed to use the same syntax), it doesn't make sense to start supporting multiple syntaxes.

I don't see the point of supporting all those compression methods, there should be one default (ttunpack-small or LZMA),

There IS one default. ttstart has supported ASM + ttunpack since before ttunpack-small existed.

That's history.

I chose to keep ttunpack (-fast in your terminology), because the newest version of it is smaller and faster than the older, pre- Greg Dietsche / myself / Samuel Stearley versions, and because sizeof(ttstart_asm_ppg) < 2 * sizeof(pstarter).

people who want another one

ttstart maintainers belong to that group of people...

Then you should make that the default, not build dozens of versions of ttstart which only confuse people.

should just change the parameter in the TPR and rebuild.

That's pretty inefficient (and therefore stupid) of a suggestion: the automated, GUI-less build of all four possible versions of pstarter + all eleven versions of ttstart, through the `tigcc` tool (instead of `sed`/`perl` + `tprbuilder` to modify the TPR) takes less than two seconds on my computer.

But it leaves users confused about which version to use. Regular users should get one default version, advanced users can recompile.

ttstart 2.x has the capability of handling multiple compression formats in a single executable. That must be tested, right ?(I guess that the testing work can be narrowed a bit down from 11, or 23, executables, but that's still some testing work).

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