Why does Linux needs both pid_max and threads-max?

I understand the difference between /proc/sys/kernel/pid_max and /proc/sys/kernel/threads-max. There's a good explanation at the answer to [Understanding the differences between pid_max, ulimit -u and thread_max](https://unix.stackexchange.com/a/345052/273579) : > /proc/sys/kernel/pid_max has nothing to do with the maximum number > of processes that can be run at any given time. It is, in fact, the > maximum numerical PROCESS IDENTIFIER than can be assigned by the > kernel. > > In the Linux kernel, a process and a thread are one and the same. > They're handled the same way by the kernel. They both occupy a slot > in the task_struct data structure. A thread, by common terminology, > is in Linux a process that shares resources with another process (they > will also share a thread group ID). A thread in the Linux kernel is > largely a conceptual construct as far as the scheduler is concerned. > > Now that you understand that the kernel largely does not differentiate > between a thread and a process, it should make more sense that > /proc/sys/kernel/threads-max is actually the maximum number of > elements contained in the data structure task_struct. Which is the > data structure that contains the list of processes, or as they can be > called, tasks. However, effectively, both limit the maximum number of concurrent threads on a host. This number will be - to my understanding - the minimum of pid_max and threads-max. So why are both needed? I understand that the default value pid_max is [based on the number of possible CPUs](https://stackoverflow.com/a/39631072/8529284) of the machine while the default of threads-max is derived from the [number of pages](https://stackoverflow.com/a/21926745/8529284) . But since both have the same effect, couldn't Linux just have one value that would be the minimum of both?