Well, design patterns are exactly that; conceptual patterns for the development of algorithms, not necessarily implementations of said pattern that work in the general case. As such, libraries that provide "built-in" functionality may use a particular pattern, and may even be shining examples of the use of said pattern, but they aren't THE pattern. You don't need a StrategyProvider class that can be configured to meet any need, you just define a set of classes and structure them to follow the Strategy pattern.
The idea is intriguing. It looks like it would work well for document organization, flow-charting, social networks, etc etc. However, its implementation in each of those scenarios would be quite different, and while there's overlap it may be impossible to create one implementation that meets the requirements of all these scenarios, without exhibiting "inner-platform effect" (an object/library/application so complex and configurable that it basically becomes a reimplementation of the IDE used to build it).