Basically at the moment I use a fairly generic Request object to pass around "filtered" data from POST/GET. It's the only Request object created - and get's passed around as a referenced parameter (thus its the only instance of the object actually used).
I don't use a dynamic form, i.e. if I need to pass additional data between layers I'll use a completely separate object, maybe a SessionData or ViewData depending on use (and to prevent any erroneous overwriting). The Request set method is actually there to facilitate unit testing (aha

), which I've been using with pretty positive results.
Solution? Exactly what you said: push filtering later into the program. Factor your filter logic into two types: types that determine exactly how the data has to be filtered, and logic that requires the information be filtered.
That sounds eerily like the messy solution I suggested

. I passed over it because pushing actual filtering further back onto commands themselves seemed to be allowing unfiltered data move freely through the prior one or two layers (where it might potentially do something *bad* - more a risk than a certainty).
Your filtering probably shouldn't be discarding information you need later. Perhaps you need to parse and extract the data into the multiple request objects you described as messy?
Maybe so - but that means maintaining the original data, which in an Register_Globals On environment may be an additional security risk - which I would prefer to avoid of possible. I think maybe I AM being too strict...
The "babbling" did make sense - I thought I was the one babbling...
Just to check we're on the same page, I'm assuming that by "command" you mean there are a range of possible commands associated with a single request type?
Well the idea behind the system is for a Front Controller to map a request to a Handler/Command. Generally if the request will invoke a series of Commands - the FC should map to an Application Controller which can use some internal stored State to determine what Commands (whether single, or in series), and in what order, should be invoked. The term Command refers to the pattern some object containing application logic follows - basically say a DoThis or DoThat or AddThis set of objects which reflect an "action", bundled into an execute() method.
As an example, a user enacts an action which will begin a process. Now say the process requires three Commands (an object which executes a set of discrete application logic), to be run one after the other without any further input from the user. So basically you get a queue of commands to be executed. A more familiar example - though more a specialised form of the AC - might be a multi-page form, where some form pages can be skipped depending on input - the AC would control this using some internally stored State. A state could be something as simple as a flag set in $_SESSION just to show what I mean by the term. I think the term Transition is more commonly used to describe the passage of control between Commands in a queue...
Now for this example the AC would run Command1, Command2, Command3 in succession, and then invoke a View of some description. The current system would filter data based on Command1 - ignoring the rest, and deleting any data they may require since not expected by the FilterData Object for Command1. If that makes sense...
Back on topic...
Part of the problem is that there's no way to know beforehand which commands will be called after Command1 (i.e. there no existing State to predict that yet - since Command1 has to issue an updated State for the AC to continue to any other Command). It's beginning to look more and more like multiple Request objects isn't it?