I fiddled with my four-bit decoder a bit and adapted it to run a hexadecimal seven-segment display. I ended up using fourteen pressure plates and twenty-two connections. Far from optimal, but lowering it would have made the pathing even more convoluted. It could be ran while cycling, but i used it to "read" the four-bit input upon demand and activate the seven latches that hold the bridges making up the display.
The obvious problem was timing - bridges as display meant i needed a safe 200-step delay before each read, so the "reset" of the latches would take before new input was received; i couldn't rely on sending the signals before the latch plates went off. So, the cart'd be started via hatch-drop on a ramp, sending resets to all latches, but also sending "on" signals to a grate and raising bridge. It would then cycle around and stop on top of the grate. Once the signal registered, the grate would drop the cart into another pit, the exit of which would now be blocked by the raised bridge. Only after the accompanying "off" registered and caused the bridge to lower again would the cart leave the pit and go through the actual reading sequence, sending the appropriate set signal(s) to the appropriate latches which would retract the required bridges in the display.
Of course, i first linked the self-shut for the hatch to the wrong plate (would get re-activated, so it actually repeated endlessly) and the corrected one was just outside of the pit, thus _toggled_ bridge and grate instead of causing them to cycle. After fixing those various misfunctions, it works adequately. In the fastest case, the set signal to the latch is sent ~45 steps after the display bridge(s) extend.
And i built a powerless minecart thumper. It cycles rather slowly and takes a bit much space, so i'm not too interested in actually using it, but the test also shows that if the design is at below-derail speed, cargo stays inside the cart and can increase the punch delivered dramatically. I reluctantly expended a kitten for the test.
The gemsetter finally mooded. She made some uninteresting milk quartz chest, but more importantly, she's a legendary gemsetter now. Her only job is pimping our rides, so i guess it's time to break out the diamonds.
EDIT - pics:
Seven-Segment Display Controller
Clearly bears no resemblance with a standard electronics seven-segment display controller. With minecart pathing, it's actually _easier_ mechanics-wise to split the input into the full sixteen outputs and it'd be disproportionally _harder_ to run it through the ~30 logic gates applied in mechanical and fluid logic (you could do this with a stupefying number of dedicated minecart logic circuits, each taking its own switch logic and its own minecart, but that'd be ridiculously inferior to just using mechanical logic). Signals arrive at wildly varying times depending on the paths chosen. Real-time display is pretty much out, instead the segments themselves are run through the latches visible to the right in the first screenshot. I collected and crossed some paths to reduce the number of connections required - only "segment off" signals must be sent, all latches are re-set and bridges returned to visibility upon each read, so we'd have at worst 34 connections from the output plates themselves (going with full hexadecimal). I got the number down to 22 and reducing it further to 17, possibly less, should be possible with significantly screwier pathing. Several outputs are combined and pass over the plates for numbers 6 (signal right upper segment) and 9 (signal left lower segment) respectively, saving a full ten connections. Notably, number 5 needs no own output plate, because it's guided over both the six and nine plates. The outputs of 4 and 7 are guided over the output plate for A, saving another two connections. With a better overall layout, the 1 could also be sent across that plate (as well as intersecting the 0 output); as is, the 1 output path is almost all the way to the right and i couldn't re-design the pathing that fundamentally without ripping everything out.