Reliability is a very different issue to all of the other issues addresses above. While they require consideration in the design of the filesystem layout, and to a lesser extent the design of the code, reliability needs to be addressed in the coding process.
To some extent, nothing can replace a meticulous attention to detail and a thorough understanding of the task, the implementation, and the interfaces. However some techniques can be used to ease the task.
In my experience, two techniques that are very helpful in improving reliability are documentation and prototypes.
Possibly one of the best examples of Documentation aiding reliability is the TeX system by Donald Knuth. While it is certain that much of the credit for the success of TeX and the stability and reliability of the code can be attributed to Donald's brilliance with programming, some must certainly go to his substantial efforts to document what he was doing. The TeX program is a wonderful example of the Literate Programming style that Knuth pioneered and shows that writing technical documentation hand-in-hand with the code has very positive results.
A little closer to home, Andrew Morton - kernel hacker and ext3 developer has said more than once that the excellent documentation that Stephen Tweedie (original ext3 developer) put in the ext3 code was big part of why Andrew was able to pick up the 2.2 code base and port it to 2.4 with great success.
It recognition of this, LaFS is being documented in detail while the code is developed. While this is not a complete panacea, it will make the project much more manageable.
The other technique I suggested is prototypes. To build a good system, it is invaluable to build a good prototype first. It is also dangerous to decide that the prototype is good enough and to put it into production.
Developing a prototype is, of course, a good way to test a design. While building it you discover all the little fiddly details that you didn't think about while you were concentrating on the big picture. Some of these you fix in the prototype. Some you wont be able to because the fundamentally affect the design, and you only work around.
If you try to use the prototype in production, it will still have those warts that you couldn't completely fix and they will eventually bite you. If you throw away the prototype once finished -- keeping all the lessoned learned (in your documentation) but discarding all the code -- and start again, you will inevitably build a much better system. It can be a lot more work, but it can be worth it in the long run.
So I recommend building a prototype, preferably in a way that you cannot possibly use it in production. One approach is to write the prototype in a different language. Use a language that is suitable for prototyping but which you won't want your final product to be written in, such as Perl.
The approach used for LaFS is to build a prototype that runs as a user-space program. It can do all the file manipulations and data management that the final code will have to do, but as it runs in user-space and not kernel-space, many consideration such as locking, and memory management will be very different and so a complete re-implementation will be necessary.
Hopefully, these two techniques, together with constant attention to detail will help LaFS to be reliable and correct.