I think proper exception handling combined with reflection can produce a very readable result without the flakiness of message-eating nil:
I think that this misses the point.
The power of the message eating null is in the fact that you have a real object to pass around a system. It is an item that you can use to model things, or more precisely non-things with.
I used it to model empty slots in a model of telecoms equipment for example, and yes in the right place it can simplify implementation.
Using exception handling around a long calling chain is just not worth the effort.
As for flakiness, a generic message eating null, that does its job could be less flaky than maintianing specific null-objects for different domain models.
best regards
Keith