Catching up late with this... (thanks to Penny for pointing it out).
I'm divided about this. On one hand, it makes sense to move some langs out of the main tree to cope with the limitations CVS imposes. Of course, CVS imposes other limitations too, and I'm more keen on getting rid of CVS than of lang
That's a much harder task, so I have to agree: moving lang out of CVS can help us get through in the mid-term.
A bit of an aside follows:
I have to confess, however, that I created a couple of scripts to update/commit all-of-moodle-but-non-en-langpacks and my langpack woes have stopped 100%.
I'm conviced that all of the issues reported against having all languages in the core project can be worked around easily with all but the most broken CVS client programs. Anyone keen on exploring that track? I am quite familiar with most cli and gui cvs clients, and can lend a hand if someone volunteers to do the writing.
As it stands, we will need a little "howto" for langpack maintainers on how to deal with the separate directory, etc. Why not spend that same effort in teaching them how to use their cvs client program effectively with the current arrangement? We can even do smart things with cvswrappers to prevent frequent mistakes (commits to lang on a branch, for instance).
One part I am not convinced about is having languages in moodledata. It does make sense to have it in a separate directory from the "en" that remains in core, so as to make it easier for people to do a nested checkout (cvs, for all its warts, supports nested checkouts), and generally being able to update the langpacks without too much hassle.
Putting them in moodledata means that they are writable by apache. Langpacks are being interpreted as PHP -- having them writable by the webserver means paving the way for security breaches.