Tutorial walkthrough creates wrong results

Describe the bug I'm running through the tutorial for the Main deploy and I'm getting what I believe is incorrect results.

I've set up the main.bicep per the tutorial and deployed it via:

New-AzSubscriptionDeploymentStack -Name 'mySubStack' `
   -Location 'eastus' `
   -TemplateFile './main.bicep' -verbose

DeploymentId                : /subscriptions/413218c7-e7ee-43a5-9093-da39ded5eb45/providers/Microsoft.Resources/deployments/mySubStack-2023-02-02-19-56-35-44358
Resources                   : /subscriptions/413218c7-e7ee-43a5-9093-da39ded5eb45/resourceGroups/test-rg1
                              /subscriptions/413218c7-e7ee-43a5-9093-da39ded5eb45/resourceGroups/test-rg1/providers/Microsoft.Network/publicIPAddresses/pubIP1
                              /subscriptions/413218c7-e7ee-43a5-9093-da39ded5eb45/resourceGroups/test-rg2
                              /subscriptions/413218c7-e7ee-43a5-9093-da39ded5eb45/resourceGroups/test-rg2/providers/Microsoft.Network/publicIPAddresses/pubIP2

I then change line 22 to use static

    allocationMethod: 'Static'

and rerun the stack deployment

C:\Temp\BicepStacks> New-AzSubscriptionDeploymentStack -Name 'mySubStack' `
>>    -Location 'eastus' `
>>    -TemplateFile './main.bicep' -Verbose
VERBOSE: Using Bicep v0.14.6
VERBOSE: Performing the operation "Update" on target "mySubStack".

Confirm
The DeploymentStack 'mySubStack' you're trying to create already exists in the current subscription. Do you want to overwrite it with the following actions?
Detaching: resources, resourceGroups
[Y] Yes  [N] No  [S] Suspend  [?] Help (default is "Y"): y
VERBOSE: 1:57:29 PM - Checking stack deployment status
VERBOSE: 1:57:34 PM - Checking stack deployment status
VERBOSE: 1:57:39 PM - Checking stack deployment status
VERBOSE: 1:57:44 PM - Checking stack deployment status
VERBOSE: 1:57:50 PM - Checking stack deployment status
VERBOSE: 1:57:55 PM - Checking stack deployment status

Id                          : /subscriptions/413218c7-e7ee-43a5-9093-da39ded5eb45/providers/Microsoft.Resources/deploymentStacks/mySubStack
Name                        : mySubStack
ProvisioningState           : succeeded
ResourcesCleanupAction      : detach
ResourceGroupsCleanupAction : detach
DenySettingsMode            : none
Location                    : eastus
CreationTime(UTC)           : 2/2/2023 7:56:34 PM
DeploymentId                : /subscriptions/413218c7-e7ee-43a5-9093-da39ded5eb45/providers/Microsoft.Resources/deployments/mySubStack-2023-02-02-19-57-30-c4a0e
Resources                   : /subscriptions/413218c7-e7ee-43a5-9093-da39ded5eb45/resourceGroups/test-rg1
                              /subscriptions/413218c7-e7ee-43a5-9093-da39ded5eb45/resourceGroups/test-rg2
                              /subscriptions/413218c7-e7ee-43a5-9093-da39ded5eb45/resourceGroups/test-rg2/providers/Microsoft.Network/publicIPAddresses/pubIP2
                              /subscriptions/413218c7-e7ee-43a5-9093-da39ded5eb45/resourceGroups/test-rg1/providers/Microsoft.Network/publicIPAddresses/pubIP2
DetachedResources           : /subscriptions/413218c7-e7ee-43a5-9093-da39ded5eb45/resourceGroups/test-rg1/providers/Microsoft.Network/publicIPAddresses/pubIP1

If you note, the resource pubIP1 is detached, which I don't believe is correct.

The big issue, however, is that the pip pubIP2 is now created in the test-rg1 resource group (!!!)

C:\Temp\BicepStacks> get-azresource -ResourceGroupName test-rg1                                                                                                                                                        
Name              : pubIP1
ResourceGroupName : test-rg1
ResourceType      : Microsoft.Network/publicIPAddresses
Location          : eastus
ResourceId        : /subscriptions/413218c7-e7ee-43a5-9093-da39ded5eb45/resourceGroups/test-rg1/providers/Microsoft.Network/publicIPAddresses/pubIP1
Tags              : 

Name              : pubIP2
ResourceGroupName : test-rg1
ResourceType      : Microsoft.Network/publicIPAddresses
Location          : eastus
ResourceId        : /subscriptions/413218c7-e7ee-43a5-9093-da39ded5eb45/resourceGroups/test-rg1/providers/Microsoft.Network/publicIPAddresses/pubIP2
Tags              :

even though the bicep clearly states that pubIP2 should be in test-rg2

targetScope = 'subscription'

param resourceGroupName1 string = 'test-rg1'
param resourceGroupName2 string = 'test-rg2'
param resourceGroupLocation string = deployment().location

resource testrg1 'Microsoft.Resources/resourceGroups@2021-01-01' = {
  name: resourceGroupName1
  location: resourceGroupLocation
}

resource testrg2 'Microsoft.Resources/resourceGroups@2021-01-01' = {
  name: resourceGroupName2
  location: resourceGroupLocation
}

module firstPIP './pip.bicep' = if (resourceGroupName1 == 'test-rg1') {
  name: 'publicIP1'
  scope: testrg1
  params: {
    location: resourceGroupLocation
    allocationMethod: 'Static'
    skuName: 'Basic'
  }
}

module secondPIP './pip.bicep' = if (resourceGroupName2 == 'test-rg2') {
  name: 'publicIP2'
  scope: testrg2
  params: {
    location: resourceGroupLocation
    allocationMethod: 'Static'
    skuName: 'Basic'
  }
}

Note that the deployment for publicIP1 also contains pubIP2

To Reproduce Steps to reproduce the behavior:

Follow the steps in the tutorial as outlined above

Expected behavior I expect that pubIP1 be changed from Dynamic to Static and that pubIP2 NOT be created in test-rg1

Screenshots If applicable, add screenshots to help explain your problem.

Repro Environment Host OS: WIn11 Powershell Version:

C:\Temp\BicepStacks> $PSVersionTable   

Name                           Value
----                           -----
PSVersion                      7.3.2
PSEdition                      Core
GitCommitId                    7.3.2
OS                             Microsoft Windows 10.0.22621
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Server Debugging Information Correlation ID: Tenant ID: Timestamp of issue (please include time zone): Data Center (eg, West Central US, West Europe):

Additional context Add any other context about the problem here.

Azure / deployment-stacks

Tutorial walkthrough creates wrong results #89