context-providers: subnet lookup behaves differently for custom subnet group name tag vs default tag

[gradybarrett]

Context and Question

The documentation for subnetGroupNameTag specifies that it will default to the subnet type if the subnet tag is not found:

aws-cdk/packages/@aws-cdk/cloud-assembly-schema/lib/cloud-assembly/context-queries.ts

Lines 229 to 238 in cef98cf

	/**
	* Optional tag for subnet group name.
	* If not provided, we'll look at the aws-cdk:subnet-name tag.
	* If the subnet does not have the specified tag,
	* we'll use its type as the name.
	*
	* @default 'aws-cdk:subnet-name'
	*/
	readonly subnetGroupNameTag?: string;
	}

The way this is worded makes it sound like defaulting to subnet type applies to both the default, and custom tag lookups.

In the implementation, however, custom tags do not fall back to the subnet type:

aws-cdk/packages/aws-cdk/lib/context-providers/vpcs.ts

Lines 84 to 88 in cef98cf

	if (args.subnetGroupNameTag && !getTag(args.subnetGroupNameTag, subnet.Tags)) {
	throw new Error(`Invalid subnetGroupNameTag: Subnet ${subnet.SubnetArn} does not have an associated tag with Key='${args.subnetGroupNameTag}'`);
	}
	const name = getTag(args.subnetGroupNameTag || 'aws-cdk:subnet-name', subnet.Tags) || type;

Was this difference in functionality intentional?

What I expected to happen

I was hoping that for both the custom and default tag the lookup would fall back to the subnet type if the tag was not found.

In some of our account vpcs we have both centrally managed and custom subnets. The central subnets are tagged consistently and are the ones most folks use. The custom subnets often follow different tagging standards. The current behavior means that the presence of even one custom subnet in a vpc often breaks my ability to use the centrally managed subnets grouping tag.