Lack of capability with Qsys conduits

My pipelined designs are fully 'systolic' so they can stop on every clock. This sometimes creates long combinatorial ready-to-valid paths but I devised a component to break that combinatorial chain. (Altera could add this circuit in silicon, it would let the pipeline run at very near the speed-limit of the device)

I had developed my own streaming framework which turned out to be a sub-set of the Avalon ST, but with an inherent ready latency of 0. So I never even tried to understand how a non-0 ready latency works. (Don't have to ...).

I switched to using ST (upgrading most of my library) as connecting in Qsys is a lot nicer (and less error prone) then doing that in the text-editor. The draw-back are the conduits. If I were faced with your 'issue' I might try to develop a custom ST-adapter to translate a 'numbered conduit' into a 'unnumbered conduit' which you then can connect further down or up. The drawback is that it fills up the Qsys connection diagram. But as you rightfully deplore we're then doing the job Qsys should do on its own initiative ...

Actually I have ST-component with two conduits, just a simple std_logic_vector info needed by two other components. I just checked the RTL-diagram and they are connected, although the outputs have names LineCounterA and LineCounterB and the two receivers are named LineCounter. Maybe I'll have to try a more complex connection to see when it breaks.