Several obstacles are hindering your progress here.

Firstly, the order of properties within an object type is currently inconspicuous in TypeScript as it does not affect assignability. For instance, there is no distinction between the types {a: string, b: number} and {b: number, a: string} within the type system. Although there are techniques to extract information from the compiler to discern the key ordering like ["a", "b"] versus ["b", "a"], this only provides some sorting during compilation and is not guaranteed to be maintained when reading the type declaration linearly. Refer to microsoft/TypeScript#17944 and microsoft/TypeScript#42178 for insights on this topic. It remains challenging to automatically convert an object type into an ordered tuple consistently at present.

Secondly, the names of arguments in function types are purposely hidden as string literal types due to similar reasons as with object property ordering. These names do not impact assignability within the type system. Function argument names, solely serve as documentation or IntelliSense tools. Converting between named function arguments and labeled tuple elements is feasible but has limitations. Please refer to this comment in microsoft/TypeScript#28259 for further clarification. Currently, transforming a labeled tuple into an object type where keys correlate with tuple labels cannot be automated easily.

---

To bypass these challenges effectively, consider providing ample information to facilitate both object to tuple and tuple to object conversions:

const userOptionKeys = ["param1", "param2", "thirdOne"] as const;
type PositionalUserOptions = [string, number, boolean];

By having userOptionKeys identify the desired keys order in the UserOptions objects matching that of PositionalUserOptions, constructing UserOptions becomes easier:

type UserOptions = { [I in Exclude<keyof PositionalUserOptions, keyof any[]> as
  typeof userOptionKeys[I]]: PositionalUserOptions[I] }
/* type UserOptions = {
    param1: string;
    param2: number;
    thirdOne: boolean;
} */

You can also create a function to convert type PositionalUserOptions into type

UserOptions</code using <code>positionalToObj

:

function positionalToObj(opts: PositionalUserOptions): UserOptions {
  return opts.reduce((acc, v, i) => (acc[userOptionKeys[i]] = v, acc), {} as any)
}

This setup will enable you to implement a User class by utilizing positionalToObj within the constructor to establish consistency:

class User {
  constructor(...args: PositionalUserOptions);
  constructor(options: UserOptions);
  constructor(...args: [UserOptions] | PositionalUserOptions) {
    const opts = args.length === 1 ? args[0] : positionalToObj(args);
    console.log(opts);
  }
}

new User("a", 1, true);
/* {
  "param1": "a",
  "param2": 1,
  "thirdOne": true
} */ 

This approach functions efficiently from a type system perspective, but may lack clarity in terms of documentation and IntelliSense. To enhance parameter labels upon calling new User(), you might need to duplicate the parameter names - once as string literals and again as tuple labels, given the current inability to convert one form to another seamlessly.

Ultimately, the decision whether or not to pursue this method depends on your specific needs and preferences.

Playground link to code

It is possible to achieve this, although it's worth noting that the tools used are not recommended by the TypeScript team and rely on the order of instantiation for specific internal types (as indicated in the discussion regarding a union-to-tuple operation).

Despite this, it was an interesting challenge to solve, so here is the solution:

// Adapted from https://github.com/Microsoft/TypeScript/issues/13298#issuecomment-707364842
type UnionToTuple<T> = (
    (
        (
            T extends any
                ? (t: T) => T
                : never
        ) extends infer U
            ? (U extends any
                ? (u: U) => any
                : never
            ) extends (v: infer V) => any
                ? V
                : never
            : never
    ) extends (_: any) => infer W
        ? [...UnionToTuple<Exclude<T, W>>, W]
        : []
);

type Head<T> = T extends [infer A, ...any] ? A : never
type Tail<T extends any[]> = T extends [any, ...infer A] ? A : never;

type PluckFieldTypes<T extends object, Fields extends any[] =
  UnionToTuple<keyof T>> = _PluckFieldType<T, Head<Fields>, Tail<Fields>, []>
type _PluckFieldType<
  T extends object,
  CurrentKey,
  RemainingKeys extends any[],
  Result extends any[]
  > = RemainingKeys['length'] extends 0
      ? CurrentKey extends keyof T ? [...Result, T[CurrentKey]] : never
      : CurrentKey extends keyof T
        /* && */? RemainingKeys extends (keyof T)[]
        ? [...Result, T[CurrentKey], ..._PluckFieldType<T, Head<RemainingKeys>, Tail<RemainingKeys>, []>]
        : never : never;

// -- IMPLEMENTATION --
type Args = {
  param1: string,
  param2: number,
  param3: Date,
  param4: number,
  param5: string,
  param6: Date,
  param7: boolean,
  param8: boolean,
  param9: null,
  param10: 'abc' | 'xyz'
}

class CompositeClass {
  constructor(params: Args);
  constructor(param1: string, param2: number, param3: Date);
  constructor(...args: [Args] | PluckFieldTypes<Args>) {
  }
}

The type inferred for ...args ends up being

(parameter) args: [Args] | [string, number, Date, number, string, Date, boolean, boolean, null, "abc" | "xyz"]

and the second constructor shows an error until all other parameters are included.

The one limitation we encounter is the inability to enforce the argument names matching the field names (due to labeled tuples not exposing labels at the type level, making them inaccessible through built-in constructs like ConstructorArguments or within this context using _PluckFieldType.)