So here are my thoughts on that.
You need to have a common variable by changing one thing to the other. You are stuck either way because the old version doesn't have SpecTypeIds and the new version will soon not understand ParameterType. So where you target the pre ForgeTypeId API even the common code can't use them and would have to instead use string representations or your own version of the ForgeTypeId (named the same and with the same method names etc. so your common code doesn't know the difference).
In general you can solve it two ways:
1) Convert everything (old and new) from ParameterType
2) Convert everything (old and new) from SpecTypeId
i.e. the common code for all versions will be using one or the other as a base (ideally it should be using SpecTypeId).
For (1) you have SpecUtils.GetSpecTypeId
For (2) you have SpecUtils.GetParameterType (*not available in older API but input to output is easily duplicated there from new)
*Since we have this utility method in newer versions there is nothing stopping us from creating a direct mapping there, storing it and applying it also to older versions. Then the common code can still be using your version of the ForgeTypeId i.e. to convert to ParameterType for use in older API methods (via stored ForgeTypeId to ParameterType mapping).
Actually the ForgeTypeId is an incredibly simple class, it has very little functionality (you only have to duplicate the members of it you rely upon). So it would be easy within the legacy code to create your own version of it that mirrors real version only available in the new API. At some point there will be no versions of Revit needing this dummy version of ForgeTypeId however. Your dummy version will be contained in conditional compilation statement so it doesn't conflict with real version in newer API. Or perhaps you can optionally reference it from another assembly (differing assembly refs per configuration setup). There could have been an argument for Revit API development team placing these ForgeTypeIds and utility methods in a separate assembly so they could be referenced and used in older versions of common code (benefit of hindsight). Would have thought (since these things are common to multiple applications) they should be neutral and separate in that respect also. You can't really separate them out completely. Half these units and measurement types wouldn't exist anywhere else but Revit and Revit in Forge.
For all the benefits of a multi targeted projects I think occasionally there are some changes so significant that it is just vastly easier to create a new project solution. Otherwise you tie yourself up in knots with refactoring common parts and deciding on conditional compilation statements. It seems too much for me I'd rather just keep it simple.