Pas mal des utilisateurs de TIGCC utilisent GNU/Linux, mais je ne connais pas les pourcentages exacts.

Et au moins deux utilisateurs bien connus de TIGCC sous GNU/Linux n'utilisent pas KTIGCC (ou l'utilisent de manière exceptionnelle, pour le test).
(Enfin, pour ma part, j'étais utilisateur de TIGCC.)

Et si vous créez vos fichiers en dehors de l'EDI, c'est déjà là votre première erreur.

La plupart des vrais IDEs ne sont pas dérangés par cela.

La plupart des IDE enregistrent les fichiers avant de compiler, puisque c'est nécessaire pour tous les vrais systèmes de build.

Je n'apprécie pas le sous-entendu dans la dernière partie de ta phrase.

Les TPR sont un système de build simpliste, qui est mal adapté à plusieurs use cases bien identifiés, que permettent l'utilisation de `tigcc`(soit en script, soit carrément en Makefile ou autre vrai système de build).

il n'est pas prévu
de modifier la manière dont fonctionne la compilation dans TIGCC IDE / KTIGCC

Ca, on savait, mais je voulais le voir écrit en clair.

La deuxième partie de mon message se voulait plus générale que les outils en ligne de commande ("hors de l'IDE lui-même"). Qu'est-ce qui empêcherait de pousser Project -> Options hors de l'IDE ?

Que c'est une partie intégrante de l'EDI, ces options sont enregistrées dans le fichier .tpr quand on enregistre le projet (et seulement à ce moment - une fois de plus, on peut compiler un projet non enregistré!) et utilisées au moment de la compilation (directement par l'EDI depuis les structures en mémoire, sans passer par des fichiers - une fois de plus, on peut compiler un projet non enregistré! bis), je ne vois pas ce que tu veux externaliser.
Et puis la question est surtout: qu'est-ce que ça apporterait?

Si on externalise
[ul][li]la communication avec les émulateurs et les calculettes réelles[/li]
[li]le code de build du système limité et spécifique à TIGCC que sont les TPR[/li]
[li]la modification des options globales (évidemment, puisque le TPR ne sait gérer que ça) du système spécifique à TIGCC que sont les TPR, pour la compatibilité antérieure[/li][/ul]
que reste-t-il comme features vraiment utiles (comme écrit plus haut, la conversion de charset n'en est pas une) spécifiques à TIGCC IDE / KTIGCC ?
Pour être plus clair: tu veux maintenir un couplage fort [TIGCC IDE - KTIGCC] / [système de build spécifique à TIGCC] / [rares capacités spécifiques à TIGCC IDE - KTIGCC]. On se demande comment baisser ce couplage pour faciliter l'utilisation d'IDEs plus puissants, avec des comportements moins bizarres, et de vrais systèmes de build.

La seule raison pour laquelle je ne m'en suis pas rendu compte au début, c'est que je n'avais jamais utilisé un autre EDI avant TIGCC ^^

Pareil pour moi.

Quand à l'argument "je veux pouvoir tester un truc sans l'enregistrer", tu peux tout aussi bien te créer un projet "test" une bonne fois pour toutes et l'ouvrir à chaque fois que tu veux tester un truc. C'est très rapide à faire, tu ne conserves que ton dernier test sur le disque dur, ça ne colle pas des fichiers temporaires on-ne-sait où, et au moins ça permet d'adopter un comportement logique au niveau de l'EDI

Tout à fait.
C'est comme ça que fonctionnent mon fichier des tests d'ExtGraph, que j'ai aussi parfois utilisé pour d'autres tests, qui fait environ 240 KB, et l'ancien fichier de tests, utilisé à l'époque du reverse-engineering d'AMS, qui est il me semble entre 100 et 200 KB, il me semble.
Le fait d'enregistrer le projet permet de garder une trace des tests qu'on a fait et de les rejouer plus tard (ça m'est arrivé !). Le rejeu pour vérification pouvant d'ailleurs être fait par une autre personne (c'est bien pour ça que je t'ai envoyé à une époque mon fichier contenant tests et notes sur le reverse-engineering d'AMS, Kevin: faciliter la vérification de mes contributions).

even if you can justify your recommendations, people can frequently equally justify their actions against your recommendations

Keep this in mind, Kevin...