Playlists Mayhem, special characters relation with absolute/relative paths

[Yeshey]

Past three days have been hell, I have a folder full of music, a lot of them with special characters, all I want is a playlist with a relative path that can read special characters, and ended up with a giant list of weird VLC behaviour with playlists.. Even have a table to compare Windows with Linux(Kubuntu) and the behaviour seems to be the same.

VLC is able to save playlists in 3 formats: .m3u, .m3u8, .xspf;
After a lot of testing and scratching my head, it looks like VLC can save playlists with relative paths, but only if they're saved in the parent directory of the folder with the .mp3, like so:
├── Music
│ ├── [DnB] - Tristam & Braken - Frame of Mind.mp3
│ ├── [♫] Scratch21 - Sorry Jack.mp3
│ └── Tobu - Life.mp3
├── playlist(with relative path).m3u8
└── The "weird characters" in these musics is "[" and "]".txt

which is good (very weird behaviour, but good)
So now I just need a playlist that can handle all of my special characters, and at first, it seemed like all formats could play all types of weird characters, but, eghhhhhh, wrong, this has got to be unintended: (tested in windows and Kubuntu)
(1st - )If we right-click a folder with .mp3 and say to play it with VLC, it will play all the music in there in one VLC instance, including the ones with weird characters, if from that instance of VLC we make an m3u or m3u8 playlist, close VLC, and play that playlist with VLC, then it plays all those music with weird characters right! NO matter where we save it!
(2nd - )But that seems so be unexampled, if I add another music with weird characters to that playlist and save it again, ON THE FOLDER THat gives it a relative path, that song won't play. As well as if you open a fresh instance of VLC, drag music with weird characters to it, and save an m3u or m3u8 playlist in the respective relative path folder, they won't play.
Try it!
It seems that when I open it the "1st" way it encodes those weird characters differently than the "2nd" way. If I open them with a text editor, the song "[♫] Scratch21 - Sorry Jack.mp3" in the previous example, encoded as .m3u8 would look like:
(1st - )(working way)(encoding:):
#EXTM3U
#EXTINF:276,[♫] Scratch21 - Sorry Jack.mp3
Music/%5B%E2%99%AB%5D%20Scratch21%20-%20Sorry%20Jack.mp3

(2nd - )(not working way)(encoding:):
#EXTM3U
#EXTINF:276,[♫] Scratch21 - Sorry Jack.mp3
Music/[%E2%99%AB]%20Scratch21%20-%20Sorry%20Jack.mp3

So the only way to get the relative path with the weird characters is the 1st way, which is not viable for editing & adding music to playlists and stuff.
The .xspf format seems to be able to read weird characters, but it never saves with relative paths, and if I manually make it relative, then it stops reading weird characters!

Is what I'm looking for even possible?
I'm by no means a developer, but the code seems to be all there.. just not right.......
Is this some kind of beta stage? Are the playlists being worked on?
Should I file a bug report? Multiple bug reports?! Is this supposed to work like this?! It can't...
If all else fails can someone suggest me a program that can do this? A program that works on Android, Linux and Windows that can save playlists with relative paths with special characters? Or is my only option to remove all strange characters from all songs...

VLC is incredible, and I thought it was perfect... until this happened..
I'm not even sure in which forum should I put this, should I move it to another one please tell me and I shall.

Pleading for help,
An average user, who became pro because of this.

[Yeshey]

Update: (Doesn't seem like I can edit the post.? Is that possible? Am I dumb?)
Anyways, did a bit of a lot more testing and out of my modest sample of musics with weird characters it seems that VLC only fails to encode these two characters in playlists with relative paths: "[" and "]", I was pretty blown away when I took out those two characters from all the music and everything started working. I was about to file a bug report, so I decided to test everything again in the nightly builds (as of 16 August 2019), and, Lo and behold, it's fixed! (at least in Kubuntu) It's fixed! VLC can read & save relative playlists with those 2 characters! Ohh boy.. Good job developers!! If only this fix was in the latest release.. Would have saved me a hell of a lot of headaches ..
Well.., the fix was in the nightly builds all along.. If you read this far, just download them and there you go..
But that also means that.. all of this.. was kinda in vain...
All that testing...

I need a hug..

(if anyone read all of this, and got this far, would you reply something? Just one or two words, to know I'm not just shouting into the dark... )

[gtomorrow]

Just this morning I upgraded to v3.08 (macOS) and VLC still throws an error on my relative-path .m3u playlists containing "#" ("07 - Public Animal #9.flac") and just plain deletes track listings containing "[]" from its playlist ("01 The Beatles - Love Me Do [Single Version].flac"). I've noticed this behavior since the beginning of the 3.x series. v2.x didn't do this; I held off upgrading VLC on my machines just because of this bug.

I just now dragged from Finder the two tracks that wouldn't play from their playlists into VLC and they play without problem. What the hell is going on?

Let's both "shout into the dark" together!

[Yeshey]

Ho-ly Damn.! I swear this was working since VLC 3.08 came out! Just tried it again today and seems to have stopped working! I even have the playlist files that it created a couple days ago when I upgraded VLC and was working with those characters.. now it can't create playlists with the right encoding for them anymore...
However...
Our shouting hasn't been in vain.
I downloaded the latest nightly build, VLC 4.0.0, and (even tho it's slow and very crashy, (and slick btw)) it CAN do everything we have been shouting for! Seriously, it can even read the playlists with the weird encoding VLC creates now and then can't read! (all of this stands only for the playlists when saved in a folder where it gets a relative path)
So yeah, the playlists seem to have been at work.
It's up to us whether we want to use this very early 4.0.0. VLC, guess I have no choice if I want to keep managing my playlists.
Thanks for joining my miserable whining!

[gtomorrow]

It's not miserable whining, it's a legitimate bug that has been introduced in the 3.x series that apparently the VLC developers didn't think important enough to fix immediately.

[Rémi Denis-Courmont]

# is the anchor separator. If you have a hash in the file name, it needs to be encoded. As far as I am aware, VLC encodes it correctly if you save a playlist.

Brackets also have special meaning in URL - same solution.

[Yeshey]

Just passing by to say that in VLC 3.0.11 this is still an issue, I'm held back from sending a bug report because this seemed to be fixed in VLC 4.0 for what I tested back in the day. But the day VLC 4.0 will arrive still feels so far away