Since etcd enforces a distinction between "directory" keys and "file" keys, some sequences of puts that would succeed on the other backends will fail on etcd.

Put("/path/to/", "Hello")
Put("/path/to/new/node", "World!")

will succeed on Consul, but the second call will fail on etcd, since /path/to is a file.

Likewise

Put("/path/to/new/node", "Hello")
Put("/path", "World!")

will fail on etcd since /path is a directory.

I've discussed the next-gen API for etcd with some of their maintainers, and I think they're planning to remove the directory/file distinction for v3. So, this issue may sort itself out on that new API.

I'm not sure there is a satisfactory resolution that doesn't involve a trade off.

One thing that could be done is to automatically change directories to files and vice versa, but this would result in data loss, and so is probably not acceptable.

Another possibility would be for libkv to append a file node suffix to every key when using etcd. E.g.

/path/to/  -> /path/to/__data__
/path/to/new/node -> /path/to/new/node/__data__

This leads to etcd backend behaving the same way as Consul & Zookeeper, however, it makes it very difficult to allow interoperation with other clients of the data store that are not libkv-based, since the keys they see are different.

We could also just do nothing, and warn developers that writing interoperable code requires that they plan their key use carefully so they always write to a leaf node in the tree.