Azure ARM template nested template deployment won't update resources\fails to start

Question

I have the following ARM Template structure:

Parent Template
  |--Nested Template 1 
  |--...
  |--Nested Template 6

So I only have 2 levels of templates, Parent and nested.

Lets say I deploy parent to an empty resource group and everything works well. After that I delete one of the resources and want to deploy the same Parent Template with the same parameters to bring deleted resources back. But the deployment would fail saying that the resource already exists (the other, not the one i'm tried to recreate). I tried both incremental mode and full mode for deployments. If i directly invoke nested template with the missing resources it works as expected (so specifically creating a deployment with nested template only, not with parent that invokes nested template).

UPD: After some additional testing I can conclude thats even weirder then before. So I'm starting this deployment with powershell:

New-AzureRmResourceGroupDeployment @parameters

And it deploys just fine, however if I invoke the same command after the first deployment completed I would get an error:

The resource 'gggg-1s-the-wordd' already exists in location 'westeurope' in resource group 'gggg'. A resource with the same name cannot be created in location 'northeurope'. Please select a new resource name.

Is this behavior excepted? I can't seem to find anything relevant, thanks!

UPD2: It doesn't really matter if I use portal or powershell, I get the same error.

Answer 1

So with the help from Brian we were able to identify the culprit. The issue was that the WebApp had its location set to resourcegroup().location while the App Service Plan was correctly getting location from parameters. So that lead to a problem where at deployment time WebApp would deploy to the region where its App Service Plan was, but at evaluation time it would consider that this WebApp belongs to the region where the resource group was. TLDR - copy paste error, which coupled with a bug in evaluation of location in ARM lead to a quite weird behavior.