Regardless of the LOF question, the code to append import does not yet exist, so that needs to be developed.
Extending the syntax of LOF files to make use of that new code is likely to be relatively straightforward. We then have both the code in Audacity, and the ability to use it.
Now looking from the opposite direction:
If we have a GUI approach to append import, the code to do it still needs to be written. That part is the same whether using a LOF approach or a GUI approach.
I think we agreed that we would need the ability in the GUI for the user to define not only what files to import, but also what order to import them. In terms of the code, that means creating a “list” of the files. Essentially that is what a LOF file is.
Looking in a bit more detail at the LOF format:
The LOF file is plain text and is read one line at a time. The fully qualified file name of the LOF file is used to determine relative paths.
Each line may contain 0 or more “tokens” (keywords).
Tokens are identified, their associated value calculated, then checked for validity, one at a time.
When all tokens in the line have been evaluated and checked, whatever that line said is actioned, then the next line is read.
The key to this is that the first “window” token is implicit, and all other tokens are optional. Tokens are read in order, and if the line does not make sense it is ignored. This is very convenient because if we define a new token, then as long as it goes after the other non-comment tokens it will be ignored by older versions of Audacity. It also means that tokens can easily be overridden. Thus, if we specify a track offsets in the GUI, they can override track offsets specified in the LOF. Similarly if we specify “append” in the GUI, then that can override an implicit “in new track” in the LOF, or if we specify “in new track” in the GUI it can override an explicit “append” in the LOF.
I’m perhaps not explaining very well, so putting it another way:
When designing a program, there is the code that “does something” and there is the interface that allows interaction with the code. There can be more than one interface.
Example: a synthesizer “does something” (synthesizes sound) and a keyboard can be used as an interface. Often a synthesizer can be used with a “wind controller” or a “MIDI sequencer”, or a MIDI keyboard, or any other MIDI controller.
Similarly, for append import we need the code that handles append import. Text file input is one possible interface by which the user can interact with that code. A GUI would be another type of interface through which the user could interact with said code. These interfaces are not exclusive - there’s no reason why they could not coexist.
In terms of development, extending the syntax of LOF files is considerably simpler than developing an acceptable GUI, and so imho would be a good practical first step.
Taking this idea one step further, the LOF syntax could be extended to do other things, such as normalizing each file, or removing DC offset, or cross-fading, or …