Windows (DOS, actually) used to act just in that way, treating a filename as a seperate 'object' than then file extension. However, now with long filename support, 'file extension' doesn't really exist. Mostly because a 'dot' is now a valid character (along with spaces and a bunch of other nasty characters. Sorry, long time UNIX user and seeing 'whitespace' and 'special chars' used in actual filenames is ... just ... wrong). :nono2:
Filename is really just a single character string and a 'dot' just an old placeholder. Well, ok, the LAST set of characters appearing AFTER the LAST dot/period has special meaning to Windows to allow for program association.
For instance, SomeFileName.Is.Here.doc is completely valid. So the collation sequence which determines how values are sorted, is doing it's job. It's why I alwasy zero fill numbers in file names. Like 01-10 or 001-999 so that things sort correctly - according to my needs. But, the '.doc' is the piece used for the OS to associate MS Word or some other document editor to it for ease of use. Note: You can make the extensions and their associations anything you want.
The values of nothing(null), empty space and space are all seperate but can appear to be the same. So, both sets of screen prints shown are doing exactly what they are being told to do, sort in the correct collation sequence.
"ABC123 ANGLE.doc"
"ABC123 FRONT TOP.doc"
"ABC123 FRONT.doc"
Is correct because the first non-common character is A/F and A comes before F. The space between FRONT and TOP in seconed row sorts lower than a dot.
However, take the 'extensions' off:
"ABC123 ANGLE"
"ABC123 FRONT"
"ABC123 FRONT TOP"
Now adding the two statements I've made, there is no real 'extension' but just a single long filename, and the collation sequence - as we've mentioned a 'nothin' (actually, just no more characters) will sort lower than a space (between FRONT and TOP).
So, I see no problems. If you give your folders an 'extention', they'll sort the same way.