Try this
https://github.com/audacity/audacity/commit/260f6fa841966406902f398ba7ba4685075131e9

Thanks, Paul. 

At "cb3e5e6" on Win 7, I created a mono spectral selection track then created point and region labels from clicking or dragging in the track, typed arbitrary label text and exported the labels file. On importing the labels file and clicking in the labels, the frequencies were recalled correctly. Also correctly, the frequency information does not show in the label text, only the label text that I typed.   

Results are as above if I export a label file containing frequency values created from a stereo spectral selection track then import the label file. 

Unfortunately if I export a label file containing labels with no label text, whether the labels were created from a spectral selection track or just an audio track, then import the label file, the labels with no label text are not seen. This would be P1, whatever the cause is. 

Backwards compatibility is OK: labels in label files or projects created by 2.1.2 are seen whether the label text is empty or not.

Forwards compatibility: Labels in projects created by 2.1.3 are displayed correctly in 2.1.2. But as expected from looking at the labels file exported by 2.1.3, 2.1.2 sees the low and high frequency information in the label text, so the label text will not be as the user saw the labels in 2.1.3. Ideally we could write the frequency information so 2.1.3 would see it but not 2.1.2. Is that too ideal?

I can do something about the P1 issue.

The code in 2.1.2 that we can't call back, was not written with the anticipation of future changes in format.  I could do something, but it would make the 2.1.3 label file less legible.  I would have to put all new frequency selection information in lines at the end of the file.  The time and frequency information for one label would not be close together.

How important is legibility of the format?

For that matter, what is constraining me from making completely arbitrary format decisions?

Label information might be exported as .csv instead.

A fix here:
https://github.com/audacity/audacity/commit/3ef49c2c89ad80905b0913eb7c7cc7a9f54ce441

No-name labels should be all right now.

I also write the new frequency data to the .txt file only when it is defined.  Let's assume it isn't in the usual case.  Then Audacity 2.1.2 should be able to interpret the file.

But if any label has frequency data, Audacity 2.1.2 will import up to and including that label but discard the rest.  And of course, only retain the names and times.

I could make extra effort for forward compatibility, but as I said, it will make the .txt file more difficult to read, as the frequency and time information will be in separate sections of the file.

Tell me how important that is.

Re comment #4 : RM says that (low) level of loss of backward compatibility is perfectly OK.

Testing on W10 and Mac El Capitan rcf2625a

On both platforms:
a) The spectral selctions are written to the exported labels file
b) the .aup file has the selLow and selHigh data
c) Tracks edit labels shows the spectral selections
d) right click on a label and selecting Edit shows the spectral data
e) closing Audacity and re-opening the project - the spectral selections are retained.

Looks good to go

Thanks, Paul. I tested briefly on Ubuntu 14.04 and checked on Windows that labels were being exported/imported correctly with Audacity running in System language and French set in the system.  

(In reply to James Crook from comment #5)
> RM says that (low) level of loss of backward compatibility is perfectly OK.
I'm not sure that is explicitly RM provenance unless it was to be presented as a P2, which it isn't being. 

I'm very happy that we aren't now storing frequency values where low and high frequencies are both undefined. This makes it possible for labels not containing frequencies to have their correct text in previous Audacity.  

I agree it is not worth the forwards compatibility "benefit" for all frequency values to be stored at the bottom of the file. 

With the current fix, previous Audacity only gains one label containing frequencies with correct text then loses all the subsequent labels. So if consensus thinks strongly that the frequencies should go on the same line as originally intended, I am fine with that. However for viewing in text editors that don't show TAB symbols, I personally prefer the frequencies on a separate line so you can see clearly what is and is not the label text.

I documented the frequency storage as it now is at http://alphamanual.audacityteam.org/man/Importing_and_Exporting_Labels .