(prompted by a late reply on a bug already marked as fixed - custom folder structure)
The reply was about adopting some first letter uppercase vs lowercase convention to differentiate namespace (alias?) from package path in a class path.
I assume what is meant is having 'MyPath.MyClass' as a shorthand reference to 'MyApp.path.to.MyClass', while having used setAlias('MyApp.path.to', 'MyPath')?
The truth is that most languages that rely on packages don't have the AppName as first item in the path. You would use 'path.to.MyClass' and it would be assumed that it matches the folder structure starting from the source or the app folder. The avoidance of a mention of the AppName in the package path makes the code more portable (easier to re-use the same code across projects).
If you use these other languages as inspiration, 'MyApp.path.to.MyClass' could be instead expressed as package: path.to.MyClass and, optional, a second parameter that let you define a baseFolder (or namespace) 'MyApp'. I think you already have some aspect of that baseFolder functionality in, through the 'alias' property. [Wondering, could you have more than one application loaded from an index.html? If not, the appName is completely predictable and therefore of no value as information.]
This would solve the problem without requiring a mix of conventions within a single item. With editors like Sublime Text allowing to refer to folders outside of your project, it is possible to think of building a library of components re-used across applications.
There seems to be an interest from Sencha to attract people from an entreprise background (e.g., Flex). However, small deviations from the usual conventions, like the addition of MyApp at the start of the path easily create major headaches for code structure and re-use in larger applications.