Scotty:
These were exactly some of the challenges I was faced with when I set out to redesign MODx in an object-oriented fashion, and after experimenting with the various PHP 5 only features and weighing the open-source audience, I came to the conclusion that whatever the official PHP developer’s support of PHP 4 may be, the reality is we still have a few years left with a substantial number of PHP 4 environments that I didn’t want to ignore. Thus, I made it PHP-4 compatible, yet aimed to allow those using it on PHP 5 to be able to take advantage of what improvements they could (e.g. PDO emulation allowing PHP 4 users to write PDO code that would also work with native PDO). There are some rules (and thus a little added complexity) for how to do things to maintain PHP 4 compatibility with the new MODx, but overall, the only thing I felt I was really sacrificing in the implementation was being able to take advantage of exception handling.
However, I also feel that PHP 4 has reached end-of-life and is hampering more progress than I would like, so I have already started working on a PHP 5.2+ version of xPDO that will take full advantage of exception handling, variable access modifiers (private, public), and other PHP 5.2+ only features, aiming for E_STRICT compliance. And MODx classes (or any "models" built on previous versions of xPDO) will be easy to refactor for the change. But anyway, I can definitely say it is liberating (and a whole lot less frustrating) to develop for PHP 5 directly, without worrying about compatibility, and the resulting code is a little more elegant and compact, if nothing else.
< End of pointless rambling >