I don't much like refinements, but conflicting monkey patches from different third party libraries _has_ been an issue over the years.
The ruby community is not even the first one to notice that, there is plenty of literature on "selector namespaces" and "classboxes" from the smalltalk crowd.
It has been an issue, but the much less painful solution is to be more careful about monkey patches, and employ other patterns whenever possible.
In my eyes, monkey patching should only ever be considered:
1. To fix outright bugs or nasty performance issues, where the monkey patch should not have other side effects.
2. In application code, never in libraries (except as a library explicitly providing monkey patches to an application, but never as a requirement for a library to work).
3. In adding new methods, except for case 1.
Of course there'd be exceptions, but very little monkey patching I see in library code is necessary or worth it.
Inside your library, you have plenty of ways of avoiding the need: Wrap objects; convert objects; use helpers. Yes, it might not look as perfectly smooth, but I'd take that over trying to reason about code that relies on different sets of refinements in different scopes any day..
From a language designer's perspective, conflicting monkey patches seem like a problem. But if you ask Ruby users I bet 90%+ would say speed and memory usage are much bigger problems.
I don't much like refinements, but conflicting monkey patches from different third party libraries _has_ been an issue over the years.
The ruby community is not even the first one to notice that, there is plenty of literature on "selector namespaces" and "classboxes" from the smalltalk crowd.