Helping users with problems - a never ending story

When I started working with Eclipse, one of my first assignments was to refine status handling (an error handling that could handle warnings and stuff like that). Early Eclipses 3.x did not have any service that would allow for status, or error reporting. This was quite problematic, as each Eclipse component had to handle problems by its own means. Usually it was either logging problems to the .log file or opening SWT Error Dialog (you may still find some bugs like 259358). This was wrong, mostly because an error dialog should be brandable.
So, status handling was introduced, and almost all UI components started using, directly or indirectly, StatusManager. Handling errors became as simple as:

StatusManager.getManager().handle();

One central place of status handling allowed for certain customization, so a little bit later a "Phone Home" functionality appeared in Rational applications (which, as you know, are Eclipse based).

The picture is hosted at IBM help pages.

Due to the specific nature of my work (Eclipse Support), I was told very often what and how should be logged, and what Eclipse could do to help users.
I quickly understood that StatusManager being a part of UI is a big mistake (and I was not first, the bug was already opened). As time flew, I was digging deeper and deeper, and it appeared that status handling should be a part of OSGi.

The bug was fixed but at that time multiple factors prevented me from doing further work in this area. Being between jobs, I have more time now, and I found that E4 simplified reporting statuses even further - the central place is now called StatusReporter, and is an injectable service. I like that part.

What worries me is the fact that StatusReporter is an E4 service - and therefore it is impossible to capture low-level errors (like those thrown inside OSGi plugins). Eclipse is not perfect, and fast changing world (new features of OSes), virtualization solutions or even backup services may break it, hence it is important to have one, consistent status handling mechanism across the whole software stack.

On the other hand, I do wonder if implementing such a solution is really a justified effort - do you, Eclipse adopters, believe that it is worth to advocate of OSGi status handling?

For those of you, who are not yet bored, I have embedded my old and poor quality screencast which presents what could be done in status handling (you may safely start from 50%).