> a way to invalidate or clear the cache

This is already supported by the simple implementation in the patch, it's spelled `del obj.the_cached_property`.

> mock patching the underlying function for testing

This is easy to do with the current implementation, you can replace the cached-property descriptor on the class with `mock.patch`.

> consistency between multiple cached properties cached in different threads

The patch attached here is already thread-safe and will be consistent between threads.

> inability to run the method through a debugger

If you `s` in the Python debugger on a line where a property or cached property is accessed, you will step into the decorated method. I've done this often, so I'm not sure what the issue would be here.

> moving the cache valued from an instance variables to an external weakref dictionary

This would be a totally different descriptor that doesn't share much implementation with the one proposed here, so I don't see how providing the common version inhibits anyone from writing something different they need for their case.

> The basic recipe is simple so there isn't much of a value add by putting this in the standard library.

It's simple once you understand what it does, but it's quite subtle in the way it relies on priority order of instance-dict attributes vs non-data descriptors.

My experience over the past decade is different from yours; I've found that the simple `cached_property` proposed here is widely and frequently useful (basically it should be the preferred approach anytime an object which is intended to be immutable after construction has some calculated properties based on its other attributes), and additional complexity is rarely if ever needed. I think the wide usage of the version proposed here (without extensions) in code in the wild bears this out. Likely a main reason there hasn't been a stronger push to include this in the standard library sooner is that so many people are just using it from `django.utils.functional.cached_property` today.