Yep.. had the same problem with the playlist manager -to load playlist files- and my "solution" was caching the entire library to find matches by path as fast as the native methods. Then you can simple save the track paths in plain txt files and load the handle.
pathTF = '$put(path,$replace(%_PATH_RAW%,\'file://\',))$if($stricmp($ext($get(path)),iso),\',\'%SUBSONG%,)';
// iterate over entire library (I would do it with serial promises to not freeze the UI)
paths_i = fb.TitleFormat(pathTF).EvalWithMetadbs(iItems);
paths = [...paths_i]
//As long as the library has not changed from the moment you cache the paths then the idx at path is equal to the idx at pool
pool = fb.GetLibraryItems();
idx = find matches by path in the cache
handlePlaylist[i] = pool[idx];
Not suggesting you to do so, just saying it can be done with the current tools for some use-cases. In my use-case it works fine because I rebuild the cache if items are added/deleted to the library during the same session (so it doesn't break playlists, loading the wrong handle). And losing 5 secs on the background to have instant playlist loading during a session is acceptable for me (I also share the same cache between different panels).
Note how foobar needs seconds to load a playlist file, while my manager does it in ms (as long as all tracks are in the library).
In fact this is pretty sub-optimal, since foobar already has a cache of the entire library (and thus all paths) but it has not been coded in a clever way, clearly, as I reported here: https://hydrogenaud.io/index.php?topic=120929.msg996961#msg996961
Cache is rebuilt when needed.
As far as I understand your usage, the cache can be on a handleList during the same session and you only need the playlist on startup (?). That would replace its usage, although it would need a few seconds to initialize.
Clearly an addLocations method to load things as handleList would be required here, being much easier. Also a method to save fpl playlists without the dialog input.