Thanks all for the useful feedback - it's particularly useful to hear from users, as opposed to just developers.
As noted, the main reason I didn't use descriptors is because txids and inputs aren't supported. In addition, it's less than user friendly to read and edit them.
If i'm going to use Excel, i'd rather see additional field which tell type of the data so i could filter/sort it with less effort.
This an interesting point. When designing this I considered it to be more work for everyone manually editing files to add a 3rd field, which in addition increases the export file size without aiding the parsing of the file in any material way (given it's currently possible to disambiguate from the reference alone). Further, it creates additional complexity and increases the potential for mistakes due to typos. But easily sorting to differentiate between types is a good counterpoint - I'm just not sure it's worth the cost.
Then something more: I've learned that best is that a file contains - in a way or another - the version of the protocol/documentation, to allow in the future, if anything is changed/added, still handle everything correctly or know from start it's not a supported version. Of course, then the use-in-excel may no longer work.
This is generally good advice and has been suggested elsewhere. However, the 'use-in-excel' goal makes this tricky. If such a version must be specified but is not present (and all other data is fine), should the import fail? In general users won't know which version number to use, even if it is readily possible to add it (say in the column headers). Also, it's difficult to see how this format could be extended in a way that required a version number to differentiate, so again I'm not sure it's worth the cost.