TL;DR: yes, it's known. No, it's not expected to get fixed soon, if ever. --delete-removed will ignore it on download too, and not delete any such local empty directory.
S3 fundamentally is an object store, not a file system. At least that's how it was originally presented to be, and what s3cmd was written to expect. There are no such things as directories - only objects that happen to have '/' characters in their names. Then along the way, Amazon added the ability to create an empty "directory" (this is still unclear to me. it seems to require appending "_$folder$" or somesuch to the object name), which then appears in the S3 object list as a 0-length object whose name ends with '/'. s3cmd never has learned how to create such an object, and as of recently, has learned to ignore such objects when encountered. By ignoring them on the remote side, and ignoring them on the local side (only files encountered via os.walk() get put on the list of objects; directories themselves never are), even operations such as --delete-removed won't do so.
Could we special-case empty directories to not be ignored, and create them on upload and create them on download? Sure, but that would require changing how S3 thinks about objects to include directories as well as files. That's not a trivial undertaking, for what is really a corner case added by S3 later. I'd be happy to review a patch that cleanly deals with empty directories as objects.