Given:
CREATE PROCEDURE [dbo].[my_storedproc]
@param1 int, @param2 varchar(100)
AS
<>
GO
There really shouldn't be a performance difference between the 6 options since they are all executing the stored procedure and not any SQL statements directly.
However, there is no better indication of performance than testing this on your own system. You already have the 6 test cases so it shouldn't be hard to try each one.
Within this controller SP, I cannot (in any practical sense) know and declare the specific physical parameters (with their required data types) required for every possible stored proc that might have to be called
Why not? I don't see why you couldn't dynamically generate the SQL for Methods 2 and 3 based on the output of either of the following queries:
SELECT OBJECT_NAME(sp.[object_id]), *
FROM sys.parameters sp
WHERE sp.[object_id] = OBJECT_ID(N'dbo.my_storedproc');
SELECT isp.*
FROM INFORMATION_SCHEMA.PARAMETERS isp
WHERE isp.[SPECIFIC_NAME] = N'my_storedproc'
AND isp.[SPECIFIC_SCHEMA] = N'dbo';
And with that info, you could create a table to contain the various parameter values for each parameter for each proc. In fact, you could even set it up to have some parameters with "global" values for all variations and then some parameter values are variations for a particular proc.