Fanout queue semantics not correct about siberite HOT 2 OPEN

Yes, looks like siberite's fanout queues implementation is different from kestrel's.
In kestrel, one write to parent queue becomes N writes where N is the number of child queues. And this configuration is stored somewhere.

Could you clarify a bit your use case?

I wanted a producer to create a single queue and then the consumers to be able to create independent queues that follow the main producer queue.

What do you mean by follow main producer queue?
For me it looks like you want consumer groups where every consumer group has separate offset of parent queue? If so, this is already implemented as consumer group feature:

set work 0 0 10
1234567890
STORED

get work.cg1
VALUE work 0 10
1234567890
END

get work.cg2
VALUE work 0 10
1234567890
END

... 
get work.cgN
VALUE work 0 10
1234567890
END

from siberite.

Yeah, that is the workaround that I'm currently using. The reason I was looking forward to using the fanout queue feature is that it's less error-prone. With the consumer group cursors, it works pretty much the way I want it to except if I (or someone else on the team) adds a new consumer but forgets to add a cursor (.something), that code would seem to work just fine but mess the scheme up. I liked the idea of the original queue being available for future consumers to replay from the beginning (or however much of it I decided to retain).

from siberite.