In your steps to repro, you could even argue what happens now is better than having Pause do nothing. My issue is that with current behaviour, Pause and Stop don't reflect the same state whichever window you are in. There are a number of quirks with this:

* You can have a project playing when its Pause button is down, and to 
actually pause it you have to press Pause twice. 

* Stop in project B will not stop playback in project A unless you have 
already pressed Play in Project B. 

* P shortcut used in Project B will not pause playback in Project A.

I think it would probably be better to widen this bug to a Review of Transport button behaviour in multiple projects. Decide if we want to mix playback of projects like we do tracks (a lot of these issues go away if you can mix projects). I assume the current behaviour if you use Pause or Play in Project B when recording in A is deemed correct. Then probably start a companion Bug:234 Wiki page to thrash ideas around.  

I suggested in:
http://forum.audacityteam.org/viewtopic.php?f=16&t=40418&p=104150#p104131

"it would be good if you could have different projects simultaneously paused. Unpausing project A would resume playback of that one, and if while project A was playing you then switched to project B and unpaused it, B would play and A would pause (Pause button in A would depress." 

I added the -devel thread to the URL for the bug:
http://audacity.238276.n2.nabble.com/P3-ressing-Play-but-not-Space-or-clicking-on-the-timeline-in-a-second-project-when-another-is-alread-td4052548.html#a4158671

Michael suggested these ideas there:
> 2.When the user hits pause or stop on the second project, the effect
> is equivalent to pressing pause or stop on the first project (not sure
> about this).
>
> 3.If the user pauses the first project, and then hits play on the
> second project, the pause state should be saved, so that if the user
> goes back to the first project and presses play, the first project
> should resume playback location from its current location.

I agree with 3). 2) is OK if Project B has no audio or no paused audio. Otherwise I think if would be better to be able to pause projects simultaneously.

a thought experiment...

start Audacity--1 Project window, <CTRL + n>--2nd Project window; drag one Transport bar off its window, drag the other one off its window

there is no indication of which toolbar will affect which window

if you do the same with the Tools bar the mouse changes to the appropriate graphic when you move over a window so you get a visual cue

(In reply to comment #2)
I no longer have a patch running that numbers untitled projects, so see no difference between behaviour of different toolbars. If you click on a floated toolbar it does bring the project window it relates to on top, even if the toolbar is totally outside its window. So if there is an issue this seems OT to this bug?

by the time you click a Transport button to see which Project comes to front it is too late

(In reply to comment #3)
If you have multiple windows open (small) and all Transport Toolbars floating, and not overlapping each other, then the controls of any of the Transport Toolbars will control the same Audacity window. Whichever Audacity window was clicked last will play when the play button of any Transport Toolbar is clicked. and will Stop/Pause when the Stop/Pause button of any Transport Toolbar is clicked. There is no visual indication which Transport Toolbar belongs to which Audacity window.

Although this is a contrived and unlikely situation for a system with only one monitor, for a two monitor system it is quite likely that the user would have the toolbars on one screen and the Audacity windows on the other.

It would seem to me more logical for each toolbar to be tied to it's window, so that when one toolbar or window is selected, the other Audacity instances are greyed out. Each toolbar operating only on it's own window.

Currently I don't think that Transport Toolbars ever "grey out", even when unavailable.

While exploring this I notice that there is sometimes a mismatch between the Transport Toolbar status and the Transport menu items. This may be a different issue, but I don't yet know the extent of it to log as a separate bug. If the pause button is pressed in an empty project then it becomes depressed, though "Pause" is greyed in the Transport menu. Generate audio into a new track and the pause button is still depressed and pause is still greyed in the Transport menu. The "P" key cannot un-pause. Select "Play" in the transport menu and playback is in pause mode.

(In reply to comment #5)
> It would seem to me more logical for each toolbar to be tied to it's window, 
> so that when one toolbar or window is selected, the other Audacity instances 
> are greyed out. Each toolbar operating only on it's own window.
That's OK if we don't want to mix projects or don't care about controlling playback of one project from another. 

I don't think this is as important as Save dialogues not indicating the project they relate to, which has a bug report. Even if you are "too late" to realise you clicked the wrong toolbar, that experience will show you which toolbar belongs to each window. If you cut from the wrong project, you can undo it. 

I still think this is better as a separate bug (f it's worth one), linked to here because special considerations apply to Transport Toolbar. 

Also see (yet again) http://garyes.stormloader.com/its.html

> If the pause button is pressed in an empty project then it becomes depressed, 
> though "Pause" is greyed in the Transport menu. Generate audio into a new 
> track and the pause button is still depressed and pause is still greyed in 
> the Transport menu. The "P" key cannot un-pause. Select "Play" in the 
> transport menu and playback is in pause mode.
There is nothing to pause until you are playing or recording. If we want otherwise, then Pause in the menu would have to be permanently enabled, or the Pause button would have to likewise be greyed unless we were playing or recording. That would mean the ability to press Pause then Record to "arm" a recording would be gone. Being able to arm a recording is inconsistent with not being able to press Pause then Play to arm playback, which I know several users expect, thinking it's like tape deck controls.

I don't feel strongly, but I think arming Playback would be good as long as we don't lose ability for Play to restart without having to use Stop first. Since this issue is not dependent on multiple projects it would have to be a separate "Review" bug for "Unintuitive Pause behaviour". 

AFAICT there are no other inconsistencies between Transport button and Transport Menu state.

(In reply to comment #6)
> There is nothing to pause until you are playing or recording.

I agree, so as part of this review, the Pause button should not stay down when clicked if the Project is empty.

This is part of the Multi-Project Wormcan is it not?
http://wiki.audacityteam.org/wiki/The_Multiproject_Wormcan

Re comment #8 indeed it is, and it has a Multiproject keyword.
Multiproject bugs typically get lower rating than they would if single project, but unless we decide to disable multiple projects they remain as valid bugs.

Testing on latest alphas on both Mac and Windows this no longer occurs

Clicking on the Pause button in the second project no longer restarts the paused project-1.

BUT having the Pause down Project-1 prevent any kind of playback or recording in Project-2

*** STEPS UPDATED ***
Per comment #10.

No longer 'Review' it's just a regular multi-project bug.

User DJDance posted on the Forum:
>I'm currently using Audacity 2.2.2 on Windows 7 & 10. When there are 
>multiple Audacity windows open and you start playing in one window, 
>you must now stop playing in that window before you can play in another window.

> In previous Audacity versions you could simply start playing in any open 
>Audacity window and it would stop playing in the Audacity window that was >playing. This is very valuable in several ways - one way is when trying to >compare/set the same volume level in multiple windows. Another way is simply >finding the window that's currently playing can be challenging when there are >many open windows.

I am not convinced that the user is right that the behavior was different in earlier Audacities.  I tested on W10 on 2..2.0 and 2.1.3 and see the same 
behavior as we have in 2.2.2. and alpha 2.3.1.

But this use case is basically the same "bug" as define in the steps to reproduce - just without the use of the Pause button.