Yes we have, the issue in the HMAC algo you have is the double URL encoding of the date object I believe. I don’t believe many of our clients used HMAC and those that did, when we made the change, changed their client algorithms.
There’s not much we can do, we’re following the RFC in order to add flexibility to what gets encoded as part of the signature, I.e the request target, and a list of defined headers (including digest if necessary). We’ve even added legacy support for an alternate date header for clients that don’t allow this to be set (ancient .Net libs)
[edit: these changes were in fact client-requested, because our implementation was a little old and not as secure as it could be. We also put these into a major release because they were breaking changes, all the way up to 1.9 the algo was unchanged]