Don't you have targetAlias in some other lock file? Why not keep the framework key same on both V1 and V2 and add targetAlias as the new key/property on V2?

As a dev/contributor, you'd instantly recognize and as a user, it'd be a less cognitive load when coming from older versions and the former benefit applies if you maintain build pipelines.

Don't you have targetAlias in some other lock file?

targetAlias is part of the assets file, and it's not something meant for the end user, it's a restore intermediary, compared to dotnet list package, which has a json output explicitly for that.

Why not keep the framework key same on both V1 and V2 and add targetAlias as the new key/property on V2?

I thought the name targetAlias is something that we use internally, but not something a machine readable user of the dotnet list package command should know about.

it's not something meant for the end user

May be but whatever you guys design on a need to know basis always ends up on people needing to know in order to make their build pipelines work properly on edge cases.

How do you think I came to know about targetAlias? And I'm not even a full time .NET dev, you know!?

I thought the name targetAlias is something that we use internally

True but what do you call the custom build target name?

1. {Target}Alias – It already exists internally
2. {Target}Profile – I don't think we're ready to use that. Too many legacy references.
3. {Target}Build – Too generic yet it does match the intent but you can't use it without Target.

I would go with 1 since I suspect most of them who have been tinkering with build stuff knows this.