^
Two things...
1. You can already today do gapless playback with MC UPnP in a perfectly easy and regular manner, if you buy a renderer that properly supports SetNextAvTransportUri. So my recommendation to JRiver is to not waste any efforts in kludging around their own currently very good implementation of UPnP to produce a bad compromise "solution" to problems caused by other parties bad implementations of UPnP. They should rather invest their efforts in lobbying those other parties to do things right in the first place.
2. If I understand you right you are talking about having MC deliver over UPnP a "live" stream comprising several tracks stitched gaplessly together? And you are suggesting that Seeks would cause different portions of those tracks to be stitched into that live stream? Or did I misunderstand you? If this is indeed what you are suggesting, then there are two problems with the suggestion: i) it would only work if MC is the Control Point, any other CP would continue to be sending regular Seek commands to the renderer in the normal way, and the MC server won't see those Seeks and so it could not do this stitching magic in such cases, and ii) more importantly, UPnP streaming is not a synchronous delivery mechanism, and so the renderer may have a local buffer of several tens of seconds (if not minutes) of stream input; this means that even if the server where to do such stitching magic, the renderer would still continue to play through all the buffered music, so your Seeks could take tens of seconds or minutes before taking effect..
Edit: additional to point i) above, since a stitched stream would be of unknown length, the MC server cannot provide a Content-Length value, and therefore the renderer cannot calculate the destination of a Seek command, so any Seek command coming from a third party CP would at least fail, and possibly result in a CP error message...