I'm not sure about this. Anyway you look at it, it's not really good.
About repackaging the binaries: This should really be avoided, it's certainly preferred to build from source. We have a few packages that are repackages though, the most famous one is firefox of course. I wouldn't even dare to build firefox from source, I did it once or twice in the past, I don't want to do it again. So, if building from source is almost impossible, as is the case with firefox, we could repackage the binaries. But I don't see it as impossible in this case.
And if we go to the building from source route, I really have to ask: is it worth the trouble? It needs yet another package as a dependency and that one is at least a weird package. Only the fpc-sources? Why? And for what purpose? For yet another double-pane file-manager? What's so special about this one, that one of the dozen other double-pane file-managers that are available doesn't offer?
Which brings me to another option with building from source. Instead of having yet another (useless otherwise) package in our repositories, the SLKBUILD for this file-manager could also download the fpc sources, put them where it needs them and build the package.
Keep in mind, that at this point, whatever you submit, will only enter our slkbuild repo, not our main packages repo. So, if you provide an SLKBUILD, you should make sure that the same SLKBUILD works for i486 and x86_64 architectures.