I don't really like the idea (even ignoring backcompat concerns). For example, it is very easy to typo "reversed" into something else that would be considered as True. Sure, you could forbid any strings other than "reversed", but... do we really want to go there?

I'm not 100% percent sure myself. There are two things:

1. What do we want the API to look like? Here, cumulative='reversed' is better than cumulative=-1.
2. How strict are we on the inputs. In particular for bools, we usually accept any values that can be converted to bools (usually just using if param) in the code. That's okish for parameters that have only a boolean meaning (or maybe additionally None). For parmeters that can be bool or 'somestring' I really would not allow any other string inputs, they are almost always typos. - Yes I think we should go there (and for example in subplots(sharey=...) we already do).

Would introducing an enum be a good idea here? You can easily handle either the string or Enum at the top:

In [3]: from enum import Enum

In [4]: class Test(Enum):
   ...:     a = 'a'
   ...:     b = 'b'
   ...: 

In [5]: Test('a')
Out[5]: <Test.a: 'a'>

In [6]: Test.a
Out[6]: <Test.a: 'a'>

In [7]: Test(Test.a)
Out[7]: <Test.a: 'a'>

In [8]: 

and deprecate True / False / -1 ?

Not sure what the enum names should be though...

See here for my concerns on Enums: #14642 (comment)

We should have a fundamental decision if we want to generally move parameters to Enums or not. That includes a recommendation whether to use them in user code or just have them accepted for better parameter parsing. Accepting both cumutlative='reversed' and cumulative=Cumulative.reversed is fine, but I don't think it would be a good idea to have both equally mixing up in user code.

Closing as not generally perceived as an improvement.