Suggestions for EVA

[ReneZ]

Further to this:

... some flavor of the EVA format ....

Strictly speaking, most of your suggestions concern the IVTFF format, rather than Eva.
This format is intended to be able to 'host'  text in different transliteration alphabets, so the format definition needs to avoid using symbols that may appear in these alphabets. The v101 alphabet is the most difficult one to cope with in that respect.

, for uncertain spaces: when the spacing is noticeably larger than in the rest of the word but smaller than a half-space

; for half-spaces: they are not uncertain, large enough to insert a i or small e

. for full spaces (as large as the previous glyph or close)

.; for large spaces, not as large as double spaces

.. for double spaces (as large as two previous glyphs)

The problem here is that I can't change existing conventions, because that will make all existing tools fall over.
I know that there are users of the format out there, and also users of ivtt. Any changes should be rare and minor, and ideally backwards compatible.

What is, however, possible is to define additional 'dedicated comments'. These are anything that is contained between < > (carets or angular brackets). Creating some additional ones may still make some software fail, but it is a far smaller problem.

/ and \ for (large) vertical offsets with less than a full horizontal space

The backslash is part of the v101 alphabet, so cannot be used. The slash is already part of the IVTFF format.
For this case, the notation <~> is already available, even though that does not indicate whether the offset is up or down.

[e] for the rare e under a gallows leg

"[e]" conflicts with the "[:]" notation, or maybe not, because there is no ":".

This overloading of the meaning of [ ] will certainly create great complications in all existing tools. What's more:
those cases of small 'e's under gallows that exist are already accounted for both in extended Eva and v101.

Now here is a case where the proposed change concerns the transliteration alphabet rather than the IVTFF format, and of course everyone is free to define his/her own, either similar to Eva or not similar at all. In such cases, using symbols that are reserved for the IVTFF format is not a good idea.
However, there is no problem in reusing symbols from v101. For example, if you write \e instead of [e] there is no issue.

+ for the possibly fused glyphs (with a common part): a+r instead of a', a+n instead of u, etc.

The curly brackets are available to indicate connected (or fused) glyphs, but again one can define one's own alphabet in any imaginable way. The + character was not available for the IVTFF format as it is used in the v101 alphabet. However the colon ( : )  is still free.

";" conflicts with the HTML-like "@number;" or maybe not, because ";" is not really necessary after @number for parsing so I omitted it.

This is true, though as a general rule, all annotations are contained between bracket pairs, which is helpful for parsing S/W.
Dropping the semi-colon here would again affect all existing software. However, as indicated above, the colon is still free.