I've made this a separate post because it's likely to be quite long. First a general point: both of these feature requests involve significant work, and we'd need to get project approval for them. Right now, for both IMT and Transformer, I'm in maintenance mode, just doing bugfixes that are prompted by reports from users. To justify the extra work proposed here, we'd need to know who needs these features; if they're mainly for the Scraps project, what's the nature of HCMC's commitment to the Scraps project, who's using it, etc.

The request to make IDs visible and editable by the user makes sense; the only objection to it is that it's likely to be confusing to users who don't know what they're for, and also it'll involve a lot of error checking and user-informing to get around the inevitable id collisions when users forget that they've already used an id. Linking between documents is already straightforward for anyone who understands how xml:id attributes work; Claire Carlin's documents do this, by using TEI note tags like this:

<note type="link"><ref xml:id="wifes_lover" target="a_une_femme_mariee.xml sur_un_jaloux.xml la_crainte_du_cocuage.xml#vers_trente-sept remede_pour_le_cocuage.xml#deuxieme_strophe fantastique_repentir.xml#strophe_dix-huit Bosse.xml#wifes_lover">Les "Stances. A une Femme mariée", les vers "Sur un jaloux" et "Fantastique repentir" suggèrent que l'amant est un ami de l'époux, ce qui n'est pas impossible, ni dans cette image, ni dans "La femme battant son mari" de Bosse. Cette gravure représente aussi la réalisation de la peur de l'époux dans "Sur la crainte du cocuage". Le message du "Remède pour le cocuage" est qu'il faut accepter l'inévitable.</ref></note>

In other words, a note inside an annotation can link to another note inside another annotation in another document. This is much more flexible in that it allows linking to multiple targets from one link, and it allows multiple links inside one annotation. Given that this is not complicated to do, I don't know that the work to add extra code to the IMT is justified.

The template idea is a good one, and we've already discussed it at length; I'd like to do it, but it would involve a serious amount of time and work, and at the moment I don't have evidence that enough people are using IMT in ways that require this to justify it.

There's another option in both these cases, though: if these features are crucial to the Scraps project, then David could add them himself. IMT is open-source, the code is all on the Website, and the cost of one copy of Delphi at academic pricing isn't really significant. The Scraps version of IMT could either be forked completely, allowing David to create a very specialized app without the need to maintain general features for users in other contexts, or the new features could be added into the main trunk. If David and the Scraps project don't have the resources to do this, then perhaps that's an indication that they're not that vital.