I think I have a pretty good implementation of a stack data structure via a newton's cradle type thing.
The elements of the stack are binary bits, though the carts themselves are ternary, to distinguish data carts from hammer carts, which are used to pop an element. 0 carts are empty, 1 carts are partially loaded, hammer carts are fully loaded. If you can fit more than one detectable state between empty and fully loaded, the data need not be binary. It uses the cart gun mentioned earlier in the thread, with a vertical stack of carts as a 'clip', with the bottom one resting on rollers that can briefly to dispense one cart at a time. Any device that dispenses a cart whenever signaled would work. Sending a signal to the cart gun is the pop operation, while sending a cart into the input is a push operation. It will halt and send an error in case of overrun if you push more data carts than there are hammer carts loaded in the device, and do nothing if you try to pop an empty stack.
lowercase - pressure plates
UPPERCASE - hatches linked to corresponding plates
^ - up ramps
# - wall
= - tracks
+ - corner tracks
| - tracks
z
Input>>==Rr=Aa========00000000=bB=eE==<<<Cart Gun
r - triggers on any cart (data carts only, hopefully)
R - drops data carts to cart reader
a - triggers on fully loaded hammer carts (only happens if stack is empty and pop is called, can also send null signal if desired)
A - drops hammer carts to be reloaded into the cart gun
b - triggers on fully loaded hammer carts (happens whenever a cart is pushed)
B - drops hammer carts to be reloaded into the cart gun
e - error plate triggers on any cart (in case of overrun error)
E - drops cart to deal with overrun error
z-1
####### ########
#+^#+^# #^+#^+#
#|##v## ##v##|####
#|########## ####+=oX#
#+===pP=m===Wherever used data goes
############
v - downramp to hammer cart reloader
p - triggers on partially loaded carts (should only be 1 carts)
P - drops cart to wherever used data goes, pressing output plate 1 as it goes
m - output plate 0, triggers on any cart (should only be empty 0 carts)
o - overrun plate, triggers on any cart, sends error signal and halts input, linked to a latch, since it needs a continuous signal until reset
X - restart hatch, in case of overrun cart comes to rest here, can be dropped by lever or some other input
Initially, there are no data carts and the righthand side of the stack is filled with hammer carts. The maximum number of elements in the stack is the number of hammercarts initially in the stack. An input comes into the stack from the left, say, an empty cart. First it triggers plate r, but it has already passed hatch R, so this doesn't matter (unless another cart comes within 100 ticks. don't let that happen, though it would probably just bounce back up the ramp and work fine), then it hits the hammercarts, knocking the end one off, which triggers plate b, falls down hatch B, and is loaded into the hammer cart gun. That can be repeated as many times as there are hammer carts. To get that bit of data back out, send a pop signal to the cart gun, which will dispense a hammer cart, which will strike the stack, sending the most recently pushed cart (in this case, an empty cart) back the way it came. The empty cart will not trigger platen a (too light), but will trigger plate r, and will go down hatch R to the reader. There it will pass over plate p (too light), and will trigger plate m, sending a 0 signal to output. If you exceed this number, the rightmost data cart will be knocked off, and will trigger the e plate, fall down the E hatch, trigger the o plate, signaling overrun error and halting input, and will come to a stop on the X hatch, to wait for the user to deal with the situation. If you attempt to pop the stack when empty, a hammer cart will be knocked off the stack, going to the left. It will trigger plate a, which could potentially send a null signal. It then falls down hatch A and is reloaded into the hammer cart gun. Avoid simultaneously pushing and popping the stack, I'm not quite sure what would happen, but it would probably not be what you intend.
I also designed a queue, but it is more complicated and plagued by problems I'm not quite sure how to solve, like how to enqueue a cart without also dequeueing one, and how to keep the queue from migrating to the left until it jams, and how to easily clear and initialize the queue. I might post it later.