MI commands changing current thread

Hi gdb people,

We noticed that MI commands that specify --thread X or --thread-group Y leave
the current thread changed after they execute.  Is it a bug or an intentional
feature?

For example:

(gdb) i th
  Id   Target Id         Frame
  3    Thread 0x7ffff6ff5700 (LWP 19594) "test" 0x00007ffff78b7f3d in nanosleep () at ../sysdeps/unix/syscall-template.S:81
  2    Thread 0x7ffff77f6700 (LWP 19593) "test" 0x00007ffff78b7f3d in nanosleep () at ../sysdeps/unix/syscall-template.S:81
* 1    Thread 0x7ffff7fc7740 (LWP 19589) "test" 0x00007ffff78b7f3d in nanosleep () at ../sysdeps/unix/syscall-template.S:81
(gdb) interpreter-exec mi '-data-evaluate-expression --thread 2 "1+1"'
^done,value="2"
(gdb) i th
  Id   Target Id         Frame
  3    Thread 0x7ffff6ff5700 (LWP 19594) "test" 0x00007ffff78b7f3d in nanosleep () at ../sysdeps/unix/syscall-template.S:81
* 2    Thread 0x7ffff77f6700 (LWP 19593) "test" 0x00007ffff78b7f3d in nanosleep () at ../sysdeps/unix/syscall-template.S:81
  1    Thread 0x7ffff7fc7740 (LWP 19589) "test" 0x00007ffff78b7f3d in nanosleep () at ../sysdeps/unix/syscall-template.S:81

At first I was convinced it was a bug, as it seems more confusing than useful.

However, I noticed this snippet that decides if the =thread-selected notification
is shown after the MI command executes:

  report_change = (ti->num != command->thread);

It will only show the notification if the current thread number (after command
execution) doesn't match the thread specified in the command.  In other words,
it seems to say: "if the user specified --thread 2 and the current thread is now
thread 2, don't report the newly selected thread, since the front-end should
know that it sent --thread 2 in the last command, effectively changing the
selected thread".

Any tips?

Simon