normally - what I presume - this page is an action enabled statistics page for rogue systems. In my opinion you'd better off with defining RSD responses in the Response tab (Automation) for any rogue detection, first because that is automatically happening, second because some action would require too much attention doing it on the Network page (such as maintaining the exceptions list), third because a defined response can execute many actions at once.
When a host is deteced by RSD sensor it is created - unless already there - in the Detected Systems table. This table is also updated by the McAfee Agent (for existing hosts).
When you install a client and it reports in for the first time, a record also gets created in the Managed Systems table. So a host potentially could be in two places: in the Detected Systems and in the Managed systems table.
This is why I recommended using responses, because by doing so you could define multiple actions for a rogue detection: moving a system and in parallel, deleting it from Detected systems, and/or make it as an exception next time.
It could be useful to let detected systems table grow so other detection such as printers, network devices, etc. whose traffic are caught by RSD sensor, populate the table and you can use their information to define one type of RSd response: the exception response.
For "normal" detection, you can use the response to install agent, etc.
See that is the problem, we had a rogue auto response but it was seeing stuff we had already added to the exceptions list so we had to disable it. Maybe with the latest patch we just added it may have fixed it. I have added a rogue response for all printers as they are a different subnet, to be added to exceptions list. So you are saying if they are managed by an Agent then they should only go into the System Tree and not the exception list?
To answer your first question, if you install an agent on a client, then it goes to the Managed Systems table (that is, appears in the System Tree somewhere depending on possible group sorting criteria, or if there is not any, in the Lost and found group). If the rogue sensor detects that client later on, it goes to the Detected Systems table, but marked as managed.
Personally I created the rogue response the following way: if it is a non-Windows then add to the exception and immediately delete from rogue list.
Interestingly I see here some connection with my other post (http://community.mcafee.com/message/137519#137519) in a different subject, regarding that rogue sensor "seeing" devices that are already managed.
Regarding this post, I described some duplicate issue, which were the result of an issue fixed by Patch 5, but remnants of the issue (i.e. nodes) could have remained in the Detected Systems table, which should have been deleted by hand. Perhaps this is to do with your problem that you describe.