API: should the RangeIndex constructor accept start=range_index?
xref #11892 (see changes and discussion)

RangeIndex, a new Int64Index subclass that will be used as the new default index (currently) has the following signature: `RangeIndex(start=None, stop=None, step=None, name=None...)`

For converting an `xrange`/`range` object into a RangeIndex, we have the constructor `RangeIndex.from_range`.

Although it isn't documented, the current constructor supports accepting a `RangeIndex` instances as the `start` argument, in which case a copy of the original index is produced, e.g., `RangeIndex(RangeIndex(0, 10, 1)) -> RangeIndex(0, 10, 1)`.

I think this is a mistake: it is reusing the `start` parameter for a different type of argument, at odds with the documented behavior and predictable function signatures. If a user wants to create another RangeIndex from a RangeIndex, they can simply use the Index construtor, e.g., `Index(RangeIndex(...))`.

@jreback argues that not accepting a `RangeIndex` as the first argument to `RangeIndex` would be an API break, because it would create an Index constructor that is not idempotent. It would be "a major break with the current Index design".

Thoughts from anyone else?
