I really don't understand the phrase "myriad problems of project reporting." Unless you want to make it complicated, project reporting can be boiled down to a to an elegant simplicity. And at the multi-project level, it must be so in order to be truly useful without triggering conflicting messages and suboptimizing behaviors.
Project reporting should merely be a matter of relative health of the project promise of each project so that targets for management attention can be identified and appropriate shifts of resource can be considered. Since scope or quality impacts tend to be most directly understood in how much additional time will be required for changes or outcomes, and since cost is merely an product of the amount of time required and the resources required for that time, the most direct measure of the health of a project's promises is schedule status.
Especially in environments where project benefits can be accrued upon completion, speed of completion (with quality, of course) should probably be the #1, 2, and 3 considerations of a PM, since the value of most such project completions far outweigh any costs (absolute or marginal) associated with them. (Or at least they should be if the project portfolio is given serious consideration.)
Schedule status, vis a vis promises, is a matter of understanding time required to complete remaining work. Time to completion for the project is simply the sum of the time to completion for current tasks plus the anticipated/scheduled/planned time associated with future tasks. Time to completion (to handoff of outputs usable by the next resource) for the current task is simply that -- a forward-looking estimate of remaining time. Obviously this is simplified in environments in which multi-tasking is minimized, but even in such dysfunctional environments, "how long until you're done" can be easily answered on a daily basis for timely capture of status of the project's schedule promise.
From there, it's a mere matter of addition of worktime remaining and subtraction of time promised from today.
Now admittedly, in a lot of troublesome project environments, where emphasis is placed on task due-date performance and milestone schedule primacy, the noise of trying to protect individual promises (both current and future) of resources can get in the way. This is why I find the approach espoused as Critical Chain Scheduling and Buffer Management (and its multi-project application) so powerful. It drives out the noise of local resource performance in favor of a focus on project performance, and the noise of project performance in favor of organizational performance.
And it's simple, with Buffer Management providing that picture of both absolute and relative health of projects in the portfolio.
For more on Critical Chain Scheduling and Buffer Management, you might want to check out sections of a recent risk management paper devoted to planning and scheduling to make promises, and tracking their health so those promises can be kept. (That last link is probably the most cogent to this discussion, but the previous two will help in the understanding of the context.)
