3) pandora-libraries itself does not depend on those packages, so creating dependencies which are not really there, does not make much sense to me. libpnd runs perfectly fine without all those libraries.
Sorry, I misunderstood what you were doing here. I had envisioned two packages; let's call them libpnd and pandora-compat. The first, libpnd, would contain just libpnd. The second, pandora-compat, wouldn't actually contain anything, and would simply depend on all the libraries that appear in the official Pandora firmware (including libpnd); end users could install this package to quickly get all libraries that apps expect to see on a Pandora. I thought you had combined both of these into one package, pandora-libraries, but instead I see that you're using pandora-libraries just to hold libpnd. I would recommend actually calling it libpnd (that's what it is, after all), but the name hardly matters. However, I would still recommend making pandora-compat; again, it doesn't have to hold anything, it just has to depend on things.
1) Although there might be some older versions of some packages available, there are most likely at least some still missing.
Yes, but that shouldn't stop us from including what's already there. Consider a user trying to run a PND in Arch; they can search for and install packages to try to make it run, but eventually they find that one package doesn't exist. If they had installed pandora-compat, they would already know it doesn't exist. That PND won't run either way, but having the pandora-compat package saved a lot of time trying to find that out. Also, PKGBUILDS for old versions can be made gradually, even if they're not all available now.
2) I would like to avoid to pollute the normal system with old libraries. People should not be encouraged to link new applications against those old libraries.
Two things here: First, I really don't understand the problem with "polluting" the system with old libraries. The two libraries sit next to each other with different filenames and different package names. If a program asks for the new library, it'll get it; if it asks for the old library, it'll get it; if it doesn't specify which version it wants, it'll get the new one. Of all the old library packages I've seen, this is how they always work; there are no conflicts, because programs always get what they want. What makes it a bad thing?
Second, Arch Pandora users are not going to be influencing developers' choice of libraries. The only reason to put old libraries into Arch is because those old libraries are already available in the official firmware. Developers will link to those old libraries because that's what the majority of users have. If you want to encourage developers to use newer libraries, making them unavailable in Arch won't help; you'll have to convince the firmware devs to update those libraries in the official firmware. If you convince them to do that, then it's a simple matter to update pandora-compat to depend on the newer library instead of the older one.
To conclude, I really think this is the easiest way: it allows us to take advantage of existing packages rather than trying to get all of these libraries into one package. I really wish I had a Pandora now so I could make it happen, but until then I'll just have to argue
(Sorry, I hope I'm not being a jerk. I still appreciate your work!)