Analoguos COBS/R, the last sigil byte could be dropped, when it would be the only one and the then last byte interpreted as sigil byte would cause a sigil byte chain error. When decoding, such situation tells, that the whole message is without any sigil byte.

So I stumbled upon your repo when trying to find a good way to send Capnproto encoded data from MCU. Initially I was going to use the provided packing and then frame it with reverse-cobs. But then I saw the RZCOBS from the same repo owner. Anyway, I ended up using TCOBS since RZCOBS require additional processing of padded zero byte. However, on your roadmap I see that you are making comparison against the V1 of TCOBS, so you may also want to make comparison against RZCOBS too.

Change

func NewDecoder(r io.Reader, size int, multi bool) (p *decoder) 

into

func NewDecoder(r io.Reader, size int, multi bool, timeOut time.Duration) (p *decoder) 

The timeOut, if 0, does not influence the current Read behaviour. Otherwise, if a successfully decoded package needed internally more than the timeOut, Read returns together with the data an error containing a data-disruption warning.

Coding

This could be done with the help of the Go Decoder code inside tcobs.go and the COBSSpecification.

Testing

All existing Tests should pass when replacing the Go Decoder code inside tcobs.go in the same way as the Go Encoder is using the C code.

remove duplicate code this way

Using groups of Z as kind of power-of-3 numbers allows further compression:

• count = 0
• count = 1 + value, if 1 Z (1=1+0) = 1...3 (3)
• count = 4 + value, if 2 Z (4=1+3) = 4...12 (9)
• count = 13 + value if 3 Z (13=1+12) = 13...41 (27)
• ...
• Task: Convert a 0x00 count in a Z sequece.

Similar is possible with F and R. The 0xff acts as F1 and the 0xaa acts as R1.

TCOBS looks interesting. I would like to compare it against plain COBS, and other algorithms.
Can you please add some reference test data? For example, just a text file, where each line contains bytes in hex:

01 00 00 00
FF FF FF FF
01 02 01 02 AA BB AA BB
...

Of course I can just use a random data set (and this can also be included later for comparison), but reference test data are preferred, for which TCOBS is being developed in the first place. Such reference examples should at least roughly reflect typical data patterns, the approximate min/max length of messages, and serve as initial benchmark data for anyone interested.

p.s. If text files are inconvenient, the data can be saved in any other format more suitable in your opinion.

Maybe something along these lines?
https://github.com/redredgroovy/go-ffi-demo

Get rid of limitations

Coding

This could be done with the help of the C Encoder code inside tcobs.c and the COBSSpecification.

Testing

All existing Tests should pass when replacing the Go Encoder code inside tcobs.go with Go code.