-1 for the proposed change.
The umask (fs.permissions.umask-mode) is a concept that is applied at the client side by individual applications, usually via their usage of the FileSystem subclasses that implement a particular file system client. The umask is not applied by the API/protocol layer such as WebHDFS or NameNode RPC. As such, the behavior of the shell, which applies umask, is not always going to look consistent with the behavior of a direct curl WebHDFS call, which does not apply the umask.
Using the shell to access WebHDFS gives consistent results, because the logic of the WebHdfsFileSystem class used by the shell will apply the umask.
If this patch were committed, then it would become basically impossible to create files and directories with absolute permissions through WebHDFS. For example, suppose fs.permissions.umask-mode is set to 022, but an individual application has a desire to create a file with 775 permissions. This wouldn't work as expected, because server-side enforcement of the umask would restrict permissions on the resulting file to 755. The only way to work around this would be to reconfigure fs.permissions.umask-mode and restart the NameNode, which isn't operationally desirable. Worse than that, this would likely have the long-term effect of reducing fs.permissions.umask-mode to lowest common denominator, perhaps even 000, to accommodate all possible permissions at file creation time, thus weakening the benefit of umask as applied by client applications like the shell.
As a final point against this change, please note that it could be considered backwards-incompatible. In my example above trying to create a file with 775 permissions, but the server-side umask forcing it to 755, it means that subsequent write actions by users in the same group will be unauthorized. This may break certain workflows.
The area where there is a possibility for change is documentation to help raise user awareness of this. That could potentially go into the HDFS Permissions Guide page or the WebHDFS REST API page, or perhaps some combination of both. I would be happy to help review and +1 documentation changes.
Wellington Chevreuil, despite my -1, thank you for writing up your experience with this and posting a patch. If you'd like to proceed with a documentation patch, please let me know, and I'll assign the issue to you.