Once again, a gripping stream of consciousness episode! Good update. Some thoughts:
a) FreeBSD owns such a negligible share of the desktop market that they probably plain don't care that much about it. I am not sure if you know it, but *BSD (NetBSD in particular, but also OpenBSD) are huge in the porn industry. Further proof that those guys know their technology!
b) I say the above in response to your ongoing travails with Xorg. Note that Ubuntu uses Xorg too AFAIK, however there are probably more current nVidia drivers for it -- I have a dual-headed RHEL4 desktop configuration at work that works fine with the nVidia drivers installed using nVidia's recommended process. I did this all a while ago, but I will try to hunt up my notes.
c) Sendmail hacking: yes, those used to be the fun times... just trying to figure out which rulesets applied for sender rewriting took about 2 days, at least for me ;-). But it was great job security! Fortunately, those days are behind us mostly (unless you are running some big virtual domain hosting mailhub and relay). If you must suffer through sendmail, I hope you are using the m4 macros rather than editing sendmail.cf directly. By now you are probably aware that Sendmail was split into an MSA (submit agent) and MTA, only the former of which you need to run/configure to send email. The typical trick is to edit /etc/mail/submit.mc and do a 'make'. The *.mc files are processed through m4. Ping me if you want a submit.mc that implements a dumb relay with masquerading. The other option is to disable Sendmail altogether and switch to using either Postfix or Qmail, both of which are pretty easy to configure with Qmail being a bit easier (in my experience).
d) Evolution can be an annoyance but it has some interesting features that keep me returning to it every now and then. The integrated calendar client (which supports, IIRC, multiple protocols including WebDAV/CalDAV?) is one.
e) For bootup messages, don't forget the command 'dmesg' which reports kernel console messages (from the corresponding kernel buffer) that may not have been logged due to unavailability of the file I/O subsystem.
--ravi