counter intuitive remote target behavior in GDB 7.7

I'm seeing some counter intuitive remote target behavior in GDB 7.7.

We're writing a new GDB stub to replace our old GDB stub and there are
some behaviors by GDB that seem counter intuitive when talking to the
remote target.

I start GDB with an ELF file, I set debug packet (so I can see the
behavior I'm describing here), target-async, non-stop, turn off paging
(set height 0) and then I do a target remote with appropriate arguments.

NOTE: remote, not extended-remote.  We might support extended-remote in
the future, but not yet.

GDB sends a qSupported packet; we respond saying what we support; GDB is
happy with the response.

GDB sends Hg0 (select any thread), we say OK.

GDB sends QNonStop:1, we say OK, GDB sends qfThreadInfo, we respond with
a list of 50+ thread ids (the example in front of me has 65 thread ids).

qAttached -- we respond '1' (yes, we support qAttached, no you didn't
create the process / thread that you are attached to).

vCont? -- we respond with vCont;c;C;s;S;t

Everything is fine so far; *BUT*, notably, GDB has NOT asked what thread
it got when it did the Hg0 -- no qC packet has been seen.

GDB now does a vCont;t:1

To which I want to say WTF?

It *IS* okay for the user to explicitly and intentionally stop thread 1
or *MOST* threads on the system.  If you explicitly stop a thread and
you screw yourself, well it's your fault -- be more careful next time.

It is *NOT* okay for GDB to 'randomly' decide to stop thread 1 (or any
other thread for that matter).

When Hg0 was received the stub selected a good thread for GDB to stop
(in fact, the thread is likely already stopped).

GDB now does qsThreadInfo to get the rest of the thread list.  Then a
qTStatus (T0;tnotrun:0 for the example in front of me), qTfV (empty --
no thread state variables yet in the new stub).

Then '?' and a sequence of vStopped packets to get the list of currently
stopped threads.

*FINALLY* GDB issues a qC to which, in this instance we respond with
 QC41 -- thread 65.

Then it's qOffsets, qSymbol, another qTStatus, and a qTfP.

Next it does a Hg1 (the first stopped thread -- stopped only because GDB
decided to stop it!); reads the thread's registers, and reads memory at
the current pc location.

Then 4 qTStatus messages within nothing in between.

Then it goes through each of the remaining stopped threads, reads the
registers and the memory at the stopped pc location.

To summarize --

It asked the stub to pick a current thread; which the stub did.

It eventually asked the stub which thread it picked -- never using the
result; but not until after first stopping a thread of its own choosing.

It then changed the current thread several times -- throwing away the
thread selection that was done initially.

And it did a total of 6 qTStatus messages -- 4 of them without any other
messages in between.

Comments anyone?