Actually, I'm glad you wrote because I should update this post anyway. It turns out I was partially incorrect as to the cause of the problem. It is due to the mix of Linux+Apache vs Microsoft IIS, however it wasn't entirely caused by the case of the file names.
Using Fiddler2 (it's an HTTP debugging proxy, shows you all traffice between your system and the server) I was able to determine that the login screen was using javascript calls. Those javascript calls were to routines contained in virtual files managed by the script manager features of ASP.NET. ASP.NET manages the scripts by putting in links to virtual files on the server. For instance, you'll see references to the javascript source looking like this:
<script src="/WebResource.axd?d=86YQNY89tca_zcJetxWYfg2&t=633363112378379010" type="text/javascript"></script>
or this:
<script src="/ScriptResource.axd?d=lrQ2569SNiyT-bCBtCqcGHauoSbTfbc8nJZKNdeaRvNJlbWmUIX8XKy2ziC0NVL6SOwv4vGm3VnGUgXBGjVwEQ2&t=633363112378379010" type="text/javascript"></script>
The thing is WebResource.axd doesn't exist, it's a virtual file. When IIS sees that request come in, it will route the request to ASP.NET and it knows what scripts to send back in response to that request.
Now to Mosso. Mosso allows you to mix Linux hosted files with IIS hosted files. Normally this would be really cool because you can mix PHP files processed by Apache in the same folder as ASP.NET files processed by IIS. Seems like the best of both worlds. However, in this case by using Fiddler I found out that Apache was returning a 404 error for the .axd files. It appears their server was misinterpreting what it should do with virtual files. Normally it would pass any IIS file over to the Windows server but in this case, since the file wasn't there, it decided to handle the 404 error on its own.
After several online chat sessions with their tech support they finally elevated my issue to the network admins. Mysteriously the problem went away 2 or 3 days later.
When I requested more details, in order to have info for the tech support if it happens again, I was told:
We're currently unable to reproduce the error here, but we were experiencing some temporary technical difficulties during that time.
Yeah, sure. After a couple weeks of having the problem and elevating it to the admins it just happened to correct itself.
Generally speaking I have had a really good experience with Mosso. Their tech support has always been really helpful - or at least they really seemed to want to help. They're always available quickly and are quite friendly. I don't want you to think they generally brush off their customer's questions but I am a little annoyed that they didn't "come clean" on the issue.
Other than the issue listed above Able seems to run quite well on Mosso's cloud. I did have an issue with getting the original install scripts to run. That problem was because Mosso actually stores the files on Linux boxes. By default, when you transfer text files to a Linux box using FTP it changes the line terminators from CrLf to just Cr (or is it just Lf?). Since the sql scripts the installer uses are text files they got converted. It turns out sql server doesn't like getting sql scripts with the wrong line terminators so it choked on them. Once I figured that out and uploaded the sql files in binary mode it installed just fine.
You should know though that they aren't the cheapest service to host with. They cost $100 a month (though you can host many sites in your account if you want - we have 5 or 6) and an additional $5 or $10 per month for a SQL Server database (depending on the size) plus an extra $20 (I think) per month for using an SSL certificate. I'm happy with the hosting but I'm not paying for it, my client is.
Hope this helps.