I have used the second "trick" before to actually change the amount of CPU used by some projects. But MLC completely ignores it for that, so I don't know if it would be effective even for scheduling tasks in the BOINC client.
All of the existing GPU applications ignore this parameter. But the client takes it into account, independently of the project. And that's what makes the trick work.
As for CPU-only applications: Some, but not all, multithreaded applications take this parameter in order to configure their threadcount. E.g. vboxwrapper based applications do this. But these are rather the exception. (Edit,) the more general case is that the applications ignore it. The client however always respects it. (The client doesn't monitor how many percent of the CPUs a running application is using; instead the client takes for granted what the server or the app_config.xml is claiming about that.)
Another option is to tell the OTHER project that it is only allowed to run a specific number of tasks simultaneously, forcing it to leave the rest of the CPU threads available for other work,
I have seen this approach fail occasionally: While the client honors the limit of concurrent tasks per project or concurrent tasks per application, it does not always fill up the remaining CPUs with work from other projects or applications. Instead, some CPUs may be left idle.
None of this is directly Windows- or Linux-specific. Rather, this sort of behavior depends on a) the client version, b) which particular projects/ applications are active, c) which priorities the client is giving the tasks in the work buffer.
The latter point is a confused mix of project "resource share", reporting deadlines vs. estimated task durations¹, how much work was recently done for each of the active projects², and whatnot.
If you see different work scheduling behavior on Windows and Linux, it's not directly because of the OS.
________
¹) the client prioritizes work which seems to be in danger to miss the deadline
²) the client prioritizes work from projects which were not run a lot on this host in recent times