Dang it Dave. Now you have me looking at this again. Here is what I'm working with at this time... (at least this is what appears to me at this time)
(For most of us, the following is already known. I just put it down here so that we are both on the same page. (hopefully)).
The .fseq file is a pile of data that is sent out in a serial stream. To the best of my knowledge (looking through the output) there is no designation as to which prop gets which, just a pile that is sent out and the controller receives, putting the data on the ouputs per the predefined (and setup) channels. (e.g., Output channel 1 gets bits 1 through 126, Output channel 2 gets bits 127 through 219, etc.) The controller only knows what goes out on which output due to pre-defined setup. The controller doesn't even know what is on what channel (other than holding a human-readable note given during setup). It just takes the bits and sprays them down one output, then the next, then the next... and then starts again with the next stream. No actions, such as dim or brighten, is in the stream as the stream only contains a single frame of data. With each frame piling on after the other.
The last time that the data was distinguishable as to what prop is what, is during the rendering phase. At that time the list of props for a particular controller is known so that the renderer can grab the information needed to send to the controller, gathered and put in order, and then the result is recorded as the .fseq. (note - I would love to take a class on how the .fseq file is built, on both sides. I'm also retired, so I might have the time...)
I believe, but have not verified yet, that the only way to make a conversion from xLights to Vixen, we will need to gather the information from the sequencer, just like the rendering process does, and build the new files. A complete knowledge of the file structures in xLights and in Vixen will need to be known. Along with the file structure will be the "how to" of applying all the settings available for each prop, the timings, and anything else that goes into making those lights blink. The equivalent function in the "other" sequencer will also need to be known.
It is understood that there are quirks on both sides of this equation. The biggest that I can see is the constantly changing of functions (upgrades/updates) on both sides. This throws a big monkey wrench into keeping this working.
I have not had my breakfast yet, so the above may be askew. Leave it to say that the best of the best for each of the programs need to get together and pass information back and forth and come to a common ground. As they are all volunteers, this would be asking even more from a great group of folks. I, for one, don't see this happening.
BTW - I would like to thank all the programmers, contributors, and additional thinkers that have put out both products. I've shown my sequencing to other "retired IT folks" and they are in awe. The standard question is, "this costs HOW MUCH?" or "this can't be FREE! How much did it really cost?" I tend to agree with them. Unbelievable programs - at any price.