If I understand the code right, this now also requires the http request to contain the folder names next to the icon name (i.e. the relative path). My understanding of the issue was that it is desired to be able to structure icons into subfolders in the file system, but that they should all still be served the very same way to the outside - i.e. hiding their storage path. Wdyt?

Yes, you have to include the folder. After re-reading the issue I beliebe that both interpretations (supporting sub-folders and present them with or without folder-name) are possible. IMO the solution here is better, because we will run into unpredictable behavior if an icon with the same name in different folders (which is perfectly possible in a file system). Taking first/last discovered item would be non-deterministic since it depends on the order in which the folders are processed.

I'm not feeling well about that change as it changes the semantic of how icons are handled throughout openHAB. The "category" used to be a plain string so far - now it would be a path. Note that icon categories are used at many places: In the general IconProvider interface, within DSL item definitions, in sitemaps, etc. I don't see the benefit that would justify such a huge change.
Wrt duplicate files in the folder structure, we could probably define a simple rule like saying the first one found when traversing the tree is chosen.

I'm fine with that, too. I'll check how to implement it. Do you know here to document that?

Thank you!

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/custom-icons-disappears-in-openhab-3-3/136957/1

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/custom-icons-in-habpanel-not-working-anymore-since-oh3-3/137357/1