The code isn't symlinked, it's forked. The code portions from libtifiles2 are modified and the unneeded parts ripped out, likewise the integer type definitions from ld-tigcc.

OK.
libopcodes is a different beast indeed, but are the external bits of ld-tigcc and TIEmu extracted through automated means ? (for subsets of a given file, a sed script that keeps lines between by two markers would certainly do the job just fine)
The more the maintenance and building process is automated, the easier it is to make releases.

Well... IMO, it would be more important (more descriptive for users) to mention that they are for TI-68k calculators (which they are) than to mention that TICT (instead of whoever else) did the tools, wouldn't it ? What about something like "TI-68k Additional Tools [Suite]" ?

It's OK, but isn't the word "Additional" redundant? You can add "Developer" or something like that if you think "TI-68k Tools Suite" is too generic. Or "TICT TI-68k Tools Suite" maybe?

Yes, "developer" is better than "additional"
What about "TI-68k Developer Utilities" ? That would emphasize that these are "companion tools" to the main development tools that the rest of the TIGCC/GCC4TI toolchain is.

I wouldn't lose too much time on "shrn" if I were you [...]

ACK. Anyway, I didn't plan on spending time on "shrn" (other than fallout of modifications in pstarter, if any) before having unified the three other decompression files (if possible).
For testing purposes, where can I get shrnklib-compressed executables ?
[EDIT: oh, wait, I remember that the shrnklib compressor and decompressor code is in PreOS.]

By the way, the LZMA code should probably get updated to the latest LZMA SDK, which is now public domain.

Indeed, though I don't think it's that urgent.