The file selector popup is limited to a single directory (it does not support folder navigation) - so you would be limited to only being able to pick files from one place.
The folder to choose from would have to be fixed in the option definition, something like:

  { "File", FILE, "/SOUNDS/en" },

which might be a problem if you want to allow users to select a sound from a different language for example.

I think, this limitation would be absolutely acceptable for the use cases in my mind: choose config files for LUA-widgets. The widget has a special folder for this.

Another question - string options are limited to max 8 chars for the user input value.
I don't think this would be long enough for filenames; but increasing the length will increase RAM usage.

What is a reasonable size limit to cater for filenames?
Increase to 12 would cater for short file names (8.3) - is this enough?

Increase to 12 would cater for short file names (8.3) - is this enough?

IMHO: yes

Another question - string options are limited to max 8 chars for the user input value. I don't think this would be long enough for filenames; but increasing the length will increase RAM usage.

Is it worth it? People will complain about less free RAM on the older radios

Maybe I misunderstand something, but we are talking only about Widget-Options, not strings in general. So, B&W radios are not affected. And then also only those who use widget-options of the new FILE type.

Maybe I misunderstand something, but we are talking only about Widget-Options, not strings in general. So, B&W radios are not affected. And then also only those who use widget-options of the new FILE type.

Yes it's color only so the extra RAM should not be a concern.
Unfortunately because of the way the firmware works the extra RAM is needed regardless of whether you use the widget option or not, everything is statically allocated. But we are only talking about few KB and color radios have 6MB+ free RAM.