Okay, I'm closing this as rejected.  Some responses:

> I don't think that complexity or specialisation should matter.

Well, Python's supposed to be a general-purpose language;  range objects *are* generally useful for all sorts of tasks, but it's far from clear that being able to intersect them would be valuable to a wide range of people.

> Conceptually, why not bring range to its full potential using facilities that python already provides.

Because additions to the language (especially the core language, as opposed to the standard library) are far from free.  First the feature needs to be implemented, reviewed, fully tested and documented.  Then it needs to be maintained.  Other Python implementations (PyPy, IronPython, Jython, etc.) need to create their own implementations.  Text book writers need to keep up with the changes.  The addition makes the language larger,  making more to learn for students of the language and more to teach for teachers.  In this particular case, I'm worried that there's a real risk of making a poor API choice that will inhibit later language expansion---you can't just add a method to a builtin type without considering the impact on the language as a whole, both now and in the future.

So there's a significant cost in each core language addition, even for something as simple-looking as this.  And the benefits of the addition have to be weighed against that cost.  In this case, I see very little benefit---I doubt that there's a real and common need for range intersections.

And all of the above is before discussing the implementation difficulties associated with this particular feature:  it would likely require a C implementation of the gcd function, which is *not* a trivial thing to do efficiently, so we're looking at much more than just a few lines of code, with all the attendant risks of introducing new bugs.