Is there a recommended approach to configuring a NuGet package targeting multiple frameworks in TeamCity using MSBuild?

I've read a handful of posts (see references below) and have yet to find a guide on best practices that is specific to my tech stack.

The goal: Create a single NuGet package targeting multiple .NET frameworks built from a single .csproj file via TeamCity using MSBuild and NuGet.

The constraints:

Pull the code from the VCS only once.
All compiled assemblies should be versioned the same.
Single .csproj (not one per target framework).

I have two approaches in mind:

Create a single build configuration. It would contain three build steps: compile .NET 3.5, compile .NET 4.0, pack with NuGet. Each build step would be contingent upon success of the last. The only real problem I see with this approach (and hopefully there's a solution that I'm not aware of) is that each build step would require its own set of build parameters (e.g., system.TargetFrameworkVersion and system.OutputPath) to designate the unique location for the DLL to sit (e.g., bin\release\v3.5 and bin\release\v4.0) so that the NuGet pack step would be able to do its thing based upon the Files section in the .nuspec file.
Create multiple build configurations. One build configuration per the build steps outlined above. With this approach, it is easy to solve the TargetFrameworkVersion and OutputPath build parameters issue but I now have to create snapshot dependencies and share the assembly version number across the builds. It also eats up build configuration slots which is ok (but not optimal) for us since we do have an Enterprise license.

Option #1 seems like the obvious choice. Options #2 feels dirty.

So my two questions are:

Is it possible to create parameters that are unique to a build step?
Is there a third, better approach?

References:

Here is my preferred solution (Option #1):

The magic relies on an unfortunate workaround. If you're willing to make this compromise, this solution does work. If you are not, you can follow the issue that I opened on JetBrains' issue tracker.

The single build configuration looks like this:

Note the name of the first two build steps. They are, in fact, named explicitly as the TargetFrameworkVersion values for .NET 3.5 and 4.0, respectively.

Then, in the Build Parameters section, I have configured the following parameters:

And finally, the Nuget Pack step does the file path translation according to my .nuspec's files section:

<files>
    <file src="bin\release\v3.5\*.*" target="lib\net35" />
    <file src="bin\release\v4.0\*.*" target="lib\net40" />
</files>

Here is a solution taking the second approach:

The project contains the following build configurations and template:

The Shared Build Number Generator is the first build in the chain. It does nothing other than create a build number that the dependent builds will share. I am using the TeamCity-referenced plugin Shared Build Number by Nicholas Williams.

And here are the notable configurations in the build template:

Note the build number is coming from the build ID of the Shared Build Number Generator mentioned above. So, in my case, that build's ID is 14. Also note the variable %TargetFrameworkVersion% in the artifact path. Fortunately, TeamCity supports variable interpolation almost everywhere.

In order for the template to leverage the build number, it must have a snapshot dependency on that build configuration:

And, finally (regarding the template), the build parameters are nearly identical to the parameters in my preferred solution. Note the additional Configuration Parameter, however. This is what will be overridden by the inheriting build configurations:

Then, in the dependent builds, you must wire up a snapshot dependency so that the build number (inherited from the template) actually works by also taking a dependency on the shared build number build configuration: