Clearly and strictly define which data must "win" in case of conflict between fea and XML

[rimas-kudelis]

The UFO standard currently says very little about having feature.fea file in the font, and among that very little text is this paragraph:

It is important to note that the features file may contain data that is a duplicate of or data that is in conflict with the data in kerning.plist, groups.plist and fontinfo.plist. Synchronization between the files is not a requirement of this specification. Synchronization is up to the user and application developers.

As @khaledhostny said in #106 (comment):

Interaction between few data and UFO is completely undefined. What happens when a UFO glyph gets renamed or removed? What happens when both UFO and fea define kerning, anchors, or any other OpenType data?

I agree with Khaled on this. I think the format should at the very least dictate whether such data should be merged when compiling fonts and which of this data must take precedence in case of conflicts.

One of the goals of a standard should be to ensure interoperability of tools. Without dictating even that much, fully compliant tools may produce significantly different fonts from the same UFO, if one favours the data in XML, another the data in features.fea , and the third one chooses an even different approach.

Now that I think of it, what does UFO compliance even mean? The standard specifically mentions that features.fea may live in the project directory, but says nothing more. Let's say somebody writes a UFO to TTF/OTF compiler and simply ignores features.fea file entirely. Does such hypothetical compiler comply with the UFO standard at all, or does it not?

Does UFO even consider itself a standard? I don't think a good standard should leave things like this undefined.

If features.fea was only allowed because it's commonly used, but is not part of the standard otherwise, perhaps it should be moved demoted to just a file in the data directory instead (e.g. a first "common file")?