Nein, die jetzige Version in der dev speichert weiterhin den ganzen Pfad ab (ist ja auch nur ein Umstieg auf std::vector + char*).
In der feature/playlist-class ist es aktuell auch nicht drin, da habe ich nur eine sehr einfache Variante implementiert. Eine Speicherung über base-path + relative Dateinamen ist aber möglich, muss nur geschrieben werden.
Zu Speicherauslastung:
Aktuell können wir mit Rund 50 Zeichen pro mp3 rechnen (wenn die Ordner /Connie/Connie 01/Conne 001 irgendwas igendwas.mp3 heißen). Damit kommen wir auf 100kB an notwendigen Speicher. Ohne PSRAM geht sich das nicht aus, damit sollten wir aber keine großen Probleme haben (Stichwort custom allocators für std::string & std::vector). currentTrack ist uint16_t → bis 65535 Einträgen in der Playlist sind wir save :D.
Spätestens bei der playlist-class haben wir mit 32bit meeeehr als genug (noch nicht so viel, dass wir alle Atome des Universums zählen könnten, aber genug 
)
Mit relativem Pfad reduziert sich das um ~32kB. Wenn die Ordner natürlich längere Namen haben, erhöht sich der Speicherbedarf und -Gewinn bei relativen Pfaden entsprechen.
Beim Testen am Besten mit USB dran sein und VScode den seriellen Monitoren damit wir ein Stack Trace bekommen. Ansonsten ist die Suche sehr mühsam.
Ein neuer Playmodus wie AUDIOBOOK_SUBDIRECTORIES_OF_DIRECTORY wäre vielleicht als Feature sinnvoll.