Custom modules only partially functional with uppercase characters in module name

"Note that it is not necessary to use the same name for your module's folder as your machine name. You could, for example, use the folder name HelloWorld instead. "

We've always named the files to match the folder, and so the .info.yml file had uppercase characters. The module itself is listed and can be enabled, even when using camelCase naming of the files. Changing the file name to all lowercase did allow the block to show up to be added. If the info file was misnamed, then we would not have expected the module to be in the module list nor to be enabled without any errors.

"Important note: Be sure to not use upper-case letters in your module's machine name as Drupal will not recognize your hook implementations."

In my testing I had hook functions working, even with uppercase characters in their name ("myPrefix_myExampleModule_form_alter"), as long as the .module file was all lowercase.

I'm also very curious as to the reason for the switch to requiring all lowercase naming. What I have tested all works fine with uppercase characters, once I removed the line that converted all names to lowercase (note: all above testing is done on unaltered core, separate testing was done with this change). I have not been able to find any explanation for why Drupal is now requiring all lowercase naming.

The reason we are questioning this is that we have hundreds of custom modules to convert to Drupal8, all of which have been named with a mix of camelCase and underscores ("myPrefix_myExampleModule"). All of the custom code follows this naming convention. Having to follow different naming for these files and hooks is likely to lead to typos from habit. I doubt we are the only ones using camelCase and it seems like there would need to be a really good reason to add such a limitation.

No, we have never seen any issues due to camelCase naming of modules before D8. D8 is the 1st I'm seeing this listed, though it has been a while since I read over all the D7/6 docs and we've used camelCasing throughout, so it is possible we missed it and it just worked.

D8 could definitely use with better validation and notifications throughout. If file naming does require all lowercase to function, then those not following this should not have been listed or allowed to be enabled and warnings being generated would be very helpful for now. I agree that implementing a change to completely block these would need to wait for a later version to not break existing sites, but displaying warnings on the list of modules would be good to ensure it is seen before any new modules with the uppercase characters are enabled. We had several fully functional modules using camelCasing before we ran into this issue with the 1st that used blocks. I can confirm that if the info file is named with camel casing, then the module file can use it as well and all the hooks we have used do work in that file with camelCased function names. The Extend page does list the machine name with uppercase characters for these.

Personally, I'd prefer the bugs related to uppercase characters be fixed, rather than removing support for them, but it sounds like this has been an ongoing issue for some time and that is not likely to happen. Since the code we are working with uses camelCasing, that is what we are used to, and it is likely we will have some camelCased names slip through. Better validation and warnings about any modules that have machine names with uppercase characters would be a major help in catching these.