This can be reproduced with:
$ USE_PLAYBIN3 gst-validate-launcher -m -t validate.dash.playback.reverse_playback.dash_exMPD_BIP_TC1

That test will attempt to do reverse playback. From an adaptivedemux/dashdemux point of view what happens is:
* manifest is read
* streams are setup (using a certain bitrate variant for the video stream)
* playback is started, sidx is downloaded and parsed, data is pushed downstream going forward
* a flushing reverse playback seek (with a specific start position) is received 
* playback is restarted from the end
* based on the sidx table, dashdemux starts downloading chunks of GOP
* adaptivedemux detects we can switch to a higher bitrate and requests dashdemux to do so
* => The SIDX entries are wiped since they are no longer valid for that variant and therefore the sidx entries need to be re-downloaded
* When the chunk for SIDX table is downloaded, the "position" for that stream is updated to ... 0
* The next time the adaptivedemux loop is run (i.e. when a *chunk* is done downloading), it compares the stream position (0) to the configured segment.start (specified and non-0) ... and therefore assumes we're done reading that stream
* => playback stops for the video stream (the audio one carries on because there are no variants, but then the pipeline just hangs).

Note: With playbin2/decodebin2, the "switching to higher bitrate" happens quite often before the seek is received. It seems to be due to the fact that pre-rolling will consume more data downstream, and therefore adaptivedemux switches to the higher bitrate *before* the seek is received.

My gutt feeling is that when downloading SIDX "chunks", no position whatsoever should be reported/used/updated for the stream->segment. It's non-data really.