Diminishing Returns & New Perk Keywords

"1. I don't anyone could really agree on where that line is and I don't think BHVR has any idea either"

I personally think the answers are quite easy. Let's take healing. Though healing already has a built in diminishing return, where the first 100% healing speed saves you 8 seconds of healing and another 440% healing on top of that would merely save 5 extra seconds, there is a genuine issue, where a heal might end up faster than the killer can m1 consecutively. The time that takes (which I guesstime to be around 2 seconds) would be C. And some extra leverage could be added to be B.

For vaulting speed, which in the past would include leader, giving 25%. The developers have clearly decided that 25% + resilience 9% + Spine chill 6% was too fast of a vault, which would be 40%. 25% itself was fine, and we see with Lara's perk that 20% is fine too. That means the right answer for C would probably be around 30%, which is a fine place to start, while starting diminishming at 20%. etc.

"2: Given that perks can come with multiple effects, putting a formula like this in also really changes the balance equation. Imagine you had two perks that granted a 100% bonus and no special effect, and two perks that granted 50% bonus and aura read. Under your idea the latter perks suffer no penalty"

Correct, such perks would suffer no penalty, and that is in fact something we should celebrate. The fact that they suffer no penalty, if we have set correct B and C values, means they never reach problematic values. Where as if you'd have 2 stronger perks, and they would start to diminish, that means that we have determined, in balancing B and C that at that tipping point lever, they have received disproportionate levels of power as a result of that stacking, which is why those perks will be fine, even if their values have some level of diminishment.
So this is in fact great overall. The only time where it wouldn't be great is where you'd have to assume we picked the wrong values for B and C, but that's an easy numbers change, taking less than 2 minutes.

"3: There's not enough perks or slots to justify it. "

There absolutely are. Though I agree that there are no healing perk combos currently that I would warrant needing to receive diminishing nerfs, due to my disagreement with stacking healing being a problem (unless reaching tipping point levels), we have already exceeded this when it comes to vaulting speed, back in 2019. And it also effected nerfs to unrelenting stacking with other perks, that too could've benefited from this mechanic. So this system is in fact needed, and would permanently solve all forms of problematic stacking values (within the same category)

"4: … both BHVR's approach and yours don't address the idea that there could be a problematic outcome that can be achieved by multiple avenues… The problem still exists"

Simple disagreement. "General balancing issues" will still exist, but problematic stacking values will no longer exist. It's simply a different category of balancing issues that exists, which is completely unrelated to this current issue. This current issue in fact is completely fixed by this system, so that is a misconception. The problematic stacking value issue doesn't claim to solve all balancing issues in the game, but solves this particular one perfectly and indefinitely, due to our ability to determine through b and c exactly where we consider diminishing returns to be necessary, as well as allowing us to strictly define what the exact problematic value is that should never be allowed to by reached.

"It's not so much that the perks are strong because they are run in tandem"

It is very much so, as well, that when perks are ran in tandem that they cause many issues. The amounts of damage that big shoulder the burden, reassurance teams can do is completely throw off any balance in this game, which is also what ended the current highest Blight Winstreak with a 4 man out.

"And if BHVR wanted to limit SWFs from running multiple copies of a perk, they could do that by just preventing it from happening."
"This just seems to be setting up SWFs to ensure they can easily get the max value out of their perks while soloq runs into each other."

Like I said, preventing letting survivors pick duplicate perks is unnecessarily restrictive and reducing freedom, and assumes that keywords like Expertise are improperly balanced. If they are properly balanced, it won't be an issue that multiple survivors have it or "bump into each other", because the perks should provide extra value due to multiple survivors stacking it, which is why they were given the expertise keyword to begin with, exactly because of that disproportional stacking power nature. So it'd would indeed by the superior option for balancing, rather than unnecessarily restricting duplicate perks

"For the sake of argument though, let's just say BHVR isn't worried about if the system is to complex to scare off players."
I understand why, upon viewing the post originally, due to it covering it in so much detail that anyone could use it to directly implement it, that the mechanic might look intimidating. However, to the player, none of this complexity has to be visible. What is visible to them is rather intuitive:

Each value (like healing speed / vaulting speed, etc.) has a value at which it starts giving diminishing returns and a value it can never go beyond. That's literally all they need to understand.
In communication to players, let's say we want to communicate how vaulting speed diminishing returns work;

Vaulting speed: starts giving diminishing returns beyond 20% bonus speed and never exceeding 30%. Boom. Easy, intuitive, and fool proof, preventing problematic values from ever being reached.

Even the development of this system is rather easy.
1 function that let's you determine where diminishing returns should start (which determines b)
1 function let let's you set where diminishing returns can't exceed (which determines c)
1 function that checks a particular stacked value whether it's bigger or smaller than b - 10. If it's smaller, just keep the value as is. If it's not, use our diminshing formula with our b and c.

That's all there is to it. Both easy for players to understand and easy for the Devs to work with. Once the functions are implemented, all the devs have to do for every potential problematic value is defining where diminishing should start, and what it shouldn't be allowed to exceed, and they solve the problem forever

For example (just guestimated values btw):
Healing speed: Start diminishing at 400%, don't exceed 500%
Vaulting speed: Start diminishing at 20%, never exceed 30%
Lunge recovery Speed: Start diminishing at 50%, never exceed 100%
etc.

And the issue is gone forever

"Putting the formula in place creates another potential error point where the game design could get something wrong"

The beautiful thing about this system is, even if you believe a certain value is better off a hard stop, this system is still superior, because this system is both capable of acting like a direct hard stop, as well as a gradual fall off. Making it more versatile and only needing 1 solution to multiple problems. All a hard stop system would do is you needing multiple systems if another problem was better solved through a gradual fall off.
This system solved all those issues with 1 small-code solution.

"You're substantially boosting the latter perk design which has a number of balance effects. In turn you are saying a side can have more without sacrificing, while BHVR is taking the approach that any type of stacking will come with penalties."

Correct, the currently proposed diminishing returns effect does serve a different philosophy; it unnecessarily harms build variety and attacks stacking perks, that don't have to form any issue, and have decided to do so for no reason. They are attacking a problem that don't exist. The only problem with stacking perks is the ability to reach problematic values. Their current solution doesn't solve that. It randomly bullies people who run Botany with Empathic Connection, who have a mere 80% total healing speed and punches them in the face to reduce it to 65%. It makes 0 sense. And this problem doesn't have to exist, because we already have the solution in the post above.

"but treating Hyperfocus and Toolboxes as different percentages means the same problem still exists"

Like I said, random perks and items, like toolboxes, perks that give gen speed as well as hyperfocus not interacting much with neither my solution, nor the dev's solution proves my point. It's unrelated to this topic of stacking values, and simply a separate balancing issue. An issue for sure, I agree. But irrelevant to this topic of stacking values within the same category, which is what the diminishing returns update method targets.
A solution to such an issue, for example maximum overall global gen speeds is solved with ideas that are completely unrelated to how to deal with stacking values. And I do have covered topics addressing maximum gen-rush speeds, but like I said, it's simply a separate balancing issue and it's not relevant to the discussion of stacking values within the same category, neither would such topics have much to do with how we should handle stacking values within the same category.

You're presuming a level of perfection in the design that you can't guarantee will be achieved. You're adding more complexity and variability into the design that advantages a side which has coordination.

I'm not assuming perfection. I'm just assuming normal balance. Like I said, saying that survivors bumping into each other would be an issue with Expertise assumes that the lower tiers are improperly balanced and the first tier isn't. There's simply 0 reason to assume that it would be.

Players don't like this. They want to know how systems work, even when its 'well, this probably won't happen'.

The system is super transparent and easily understood;
Your vaulting speed starts diminishing beyond 20% and can't go beyond 40%. The more beyond 20% you go, what you receive back starts reducing exponentially. (And quite perfectly exponentially for a fact, by a square root amount)
This type of scaling is actually a super common practice in many games, and nowhere is it hated. The formula we use here, fun fact, is inspired by how League of Legends calculates armour % damage reduction. One of the most successful and beloved e-sports games in the world.

The issues though remain -
A: Determining the values for lots of issues will be difficult - you look to vaults and heals at an extreme edge, what would be a problematic level of gen progression? Do we base it on all four survivors or an individual? How do we factor in limited use progression of things like toolboxes vs. constants like Deja Vu? Do things like Great Skill Checks and Hyperfocus come into the equation at all?

This is plainly false. I've shown the issues that were solved. We no longer randomly bully people who run Botany + Empathic Connection for no reason whatsoever. Plus we make it impossible to reach problematic values, yet make any perk always contribute to more power.

You also once again bring up gen progression as a whole through any mechanic. Once again, that is a separate issue, that's not related to stacking values within the same category. For example, the current reduction to doing gens is one of the ways that tackles that, but it's unrelated to the current issue and mechanic being discussed. Hell, we could even have a multiplier that lowers gen speed when multiple survivors work on a generator at the same time. All cool ideas, interesting to overall game balance, yet completely irrelevant to this post and the system proposed by the devs to deal with stacking values within the same category. When we discuss bloodlust and implement an alteration, we don't complain it about not slowing down gens enough as well or trying to solve every other balancing issue in the game; They're simply separate topics

The only part that would be relevant to this post is perk like Deja Vu, Resilience stacking (not hyperfocus), and yes, there easily could be a diminishing return value for it. Assuming 450 total gen time, any speed above 20% would nearly scrape off an entire generator if the whole team ran it, so I'd set diminishing, starting at 15%, never reaching beyond 20%. Imagine you had 21% gen speed, the calculator would reduce it back to 17.72727272%

B: BHVR wants something different than what you do.

They don't want to do something different than what I want to do. They want to solve problematic stacking values. Though not only within the same category, but in concept more abroad too. However, that second part they haven't achieved with the current diminishing returns mechanic, and within the same category, they've created unnecessarily harmful sideconcequences of a bad system that doesn't accurately achieve what it's set out to do, which is stopping problematic stacked values (The Botany Empathic Connection example).

C: For the examples you cite, a hard cap more easily deals with the issue

My system is literally a hard cap + a gradual slider. It's not more complex than that, though it is more versatile, and for that, it is better. Especially because this versatility avoids more unintended harmful side-concequences, where certain perks just stop completely adding value. My system fixes that issue by allowing any perk to infinitely contribute, however, diminishingly so.

A pure flat cap, at say 100% speed of whatever would have the side concequences of:
Perk 1: gives 80% speed
Perk 2: gives 50% speed + effect 1
Perk 3: gives 20% speed + effect 2

Assume a player either wants to run perk 1 and 2, or else perk 1 or 3, in which perk 3 has lesser healing speed due to the second effect being stronger.
A purely flat cap would randomly break and destroy the balancing between the perk 2 and 3's effect. Since player 1 could only have perk 1 and 2 for 100% speed with a weaker effect, or perk 1 and 3 for 100% speed and a stronger effect, removing any reason to ever pick perk 1 and 2.
My system would solve this perfectly, and prevent the random breaking caused by a purely flat cap, allowing perk 2 to still contribute more to healing while preventing problematic values, which is why it's the superior system.

Additionally, you could also reduce calculations by just storing the square root of c directly, further simplifying the calculations ran for the diminishing formula, which is more optimized.

DiminishingReturnFormulaValues struct would then contain fields of B and SquareRootOfC and the main formula would just use SquareRootOfC directly. That way, you reduce how many times you have to call use Power and Square Roots;

(In this case, we don't raise C to the power in the constructor, so we don't need the square root in the main formula. All we need to do is raise it to the power once in the main formula there instead)