Construct: Rebuffered stream
There's no docstring for the class. What kind of thing does an object belonging to this class represent? The text from your post would make a good start.
There's no docstring for the __init__ method. What do I pass for substream? What does tailcutoff mean? Again, the text from your post would make a good start.
There are no docstrings for the cachedfrom and cachedto methods. What do these return?
The cachedfrom and cachedto methods do not take any arguments. Would it make sense for these to be properties instead of methods?
Attributes like substream and rwbuffer do not appear to be intended to be used outside of the class implementation. It is conventional to give these names starting with _. See PEP8:


  Use one leading underscore only for non-public methods and instance variables.

The idea seems to be to create an object that acts like Python's built-in buffered I/O objects. But it doesn't implement the whole interface — for example, there's no close method, no closed property, and so on.

It would make sense to inherit from the abstract base class io.BufferedIOBase so that you get implementations of all the methods (even if some of them are only stubs).
The number 128*1024 appears in two places without explanation. It should have a name, something like _chunk_size, and it might make sense for it to be a keyword argument to the constructor.
In the seek method I would use the constants io.SEEK_SET and io.SEEK_CUR instead of the numbers 0 and 1. That's because the named constants make the intention clear.
BufferedIOBase.read has this behaviour:


  If the argument is omitted, None, or negative, data is read and returned until EOF is reached.


This behaviour is not implemented by RebufferedBytesIO.read. This kind of incompatibility might prevent someone from being able to pass a RebufferedBytesIO object to a function that was expecting an io.BufferedIOBase object.
RebufferedBytesIO.read raises an exception on a short read:

if len(data) &lt; count:
    raise IOError("could not read enough bytes, something went wrong")


But for BufferedIOBase streams, short reads are possible.
The code for reading more chunks from the substream until the target position is reached is duplicated between the read and write methods. This should be refactored into its own method.
The code for doing the tail cut-off is duplicated between the read and write methods. This should be refactored into its own method.
Cutting off the tail using:

 self.rwbuffer = self.rwbuffer[removed:]


is inefficient. In the worst case this code ends up copying the whole of rwbuffer on each read or write, which would be disastrous for performance.
The logic for reading a single chunk from the underlying stream looks like this:

newdata = self.substream.read(128*1024)
self.rwbuffer += newdata


but the documentation for RawIOBase.read says:


  If the object is in non-blocking mode and no bytes are available, None is returned.


If this happens, the += will fail with TypeError: can't concat bytes to NoneType.
The logic for reading chunks from the underlying stream looks like this:

while self.moved + len(self.rwbuffer) &lt; endsat:
    newdata = self.substream.read(128*1024)
    self.rwbuffer += newdata
    if not newdata:
        sleep(0)


If the underlying stream is blocking, the sleep(0) is not necessary (because the read blocks if there is nothing to return. But if the underlying stream is non-blocking, then:


  A BlockingIOError is raised if the underlying raw stream is in non blocking-mode, and has no data available at the moment.


So in neither the blocking case nor the non-blocking case is there any obvious reason to have a sleep here.