Basically what I wanted to achieve is if a query gets fired my back end implementation reports on what is going on with this query. (how long did it take how many records and of what type etc etc.)

There are 2 approaches that can solve this problem. 

Approach1:

Write a wrapper around EntityManager that intercepts what is going on and report on it. I chose not to go this route because...

Approach2:

...I saw that the EntityManager exposes 3 events that looks like it might tell me what is going on with the queries. I implemented those 3 event handlers (Fetching,Querying,Queried), but it was a complete disaster. Those events fire nothing like you'd expect. 

And its not like they fire roughly correctly, they fire almost at random. (Even though EM works perfect) I thought that because those events are so uninformative I could come here and get someone to confirm it. That way I can safely implement approach 1 knowing that approach 2 wont work.

Unfortunately this has not happened so I believe I am doing something wrong. 

So here are my assumptions so far: (I am always guessing what EM is doing since I don't have the code)

1.) For a particular query those 3 events should tell me what EM is doing. Right?

2.) To "see" what EM loaded from the server I need to look at the EntityQueriedEventArgs of the Queried event. Item 6 explains what I needed assume to make this "work".

3.) To determine whether a query was a loaded from the server or a cache hit I check the EntityQueriedEventArgs.WasFetched & IsCompletedSynchronously. (Those two variables seem to function properly)

4.) To determine how many records were fetched from the server I check the EntityQueriedEventArgs.ChangedEntities collection as this seems to be the most accurate representation of how many records EM loaded. (why else would they be changed right? Assumptions!)

5.) If a query was served by EM's cache, there is no way to determine how many records were in that result set from any of the the 3 events. You just know the cache was hit and thats it.

6.) To keep track of what query I am actually looking at in the Queried event I tag the queries with a unique number as they enter the EM. My assumption here is that if a single query spawns multiple other events that they all will have this tag. This helps me combine all the Queried events usually resulting from a single query and extract stats from it. (A single query like the one described in the above posts could sometimes end up making five or six of those Queried events all with the same information in them. I could not find a pattern that explained why sometimes there are many queried events and why other times there are not so many)

To answer some of your questions:

Originally posted by GregD So the second query returned 11 records, not 1 - correct? And you're concerned about the small relative size difference between the two results sets (as reported by your "web development helper" tool)?

That is correct, it returned 11. 1 Customer and 10 orders. i thought something looked suspicious there. 

Originally posted by GregD Your tool determined that 95 entities were changed? How does it determine that?

By looking at EntityQueriedEventArgs.ChangedEntities.

Originally posted by GregD Don't be concerned about hurting our feelings. 8-)  If there's a problem we'll certainly fix it, but right now I don't have any idea what exactly your custom tool does, or how; or exactly how you're determining that EM is not reporting what it is doing correctly. So, fill us in.