I'm currently exploring options for updating the client to support better error info. It's a non-trivial effort.
One approach would be to leave the Boolean response in place and provide an optional callback parameter for API methods. The callback would provide information about an operation's failure. The challenge here is that the call chain for API methods is pretty deep. For example, updating Store to include an optional callback parameter means updating 4 or 5 method signatures and updating 1 or 2 interface definitions. Multiply that number by each operation and the change becomes quite significant.
The basic pattern is that bool Get calls bool TryGet which calls bool PerformTryGetAndTouch which calls bool ExecuteWithRedirect. Along the way, there are operation factories and other classes that would need the argument passed around. Exceptions are raised and swallowed throughout the call chain. I think an optional callback is the right way to go, but it will a) be a significant dev and testing effort b) require updating Enyim.Caching, not just Couchbase and c) require an upgrade to 4.0 (which I think is right anyway)
Another approach is to create some sort of server context object that keeps a stack of errors and provides methods for getting the last n errors and events that will be raised when errors occur. This approach is similar to an ASP.NET application where the Server object provides a GetLastError method and there are global events for error handling. It's obviously a disconnected approach that doesn't really give any guarantee about the relationship to errors and operations. It's a best guess... This is easiest to implement and doesn't require changing the API. But it's obviously suboptimal. It's really a programatic hook into logging...