Mohita,
Thank you so much for your reply. I didn’t realize that by creating the simplest example, I was going to bring more problems to the situation. 
Your answer raises more questions for me, coming from the "Data Dynamics Reports" (DDR) world and being completely new to ActiveReports:
* How do I know when I am using a CPL (Continuous Page Layout) and a FPL (Fixed Page Layout)?
* Are all old DDR RDLX reports CPL’s? (Our goal is to be able to use all of our old DDR RDLX reports without having to convert anything for our initial start in using ActiveReports.)
==============
Also, I figured out what the other problem was with the resources. It turns out the solution I’m converting from DDR to ActiveReports has a method that is executed in our base Page class for our ASPX pages that looks at the Thread.CurrentThread.CurrentUICulture and catches different character combinations and turns it into the matching language we support in our application.
In the case of my problem, we were capturing "en" or "en-US" and setting the Thread.CurrentThread.CurrentUICulture to the "en" version. This was causing your WebViewer to request:
<script id="resources-7.1.7470.0-en.js" type="text/javascript" src="Command=ArResource;ScriptId=resources-7.1.7470.0-en.js.ar7"></script>
… instead of …
<script id="resources-7.1.7470.0-en-US.js" type="text/javascript" src="Command=ArResource;ScriptId=resources-7.1.7470.0-en.js.ar7"></script>
Which means the ActiveReports "ar7″ handler doesn’t know to return the "en-US" localized resources if "en" is requested. Instead it returns a blank string which leaves all of the required localized javascript variables undefined. Being undefined, when the other scripts try to access those variables, an Undefined error is thrown and the rest of the scripts fail for the entire page, leaving the Viewer not rendered properly and no appropriate error handling to tell the user what might have happened.
It might be wise for the development team to consider handing back default resources for the main default language you support if a requested language code doesn’t have localized resources available; or consider having the handle return something like:
throw new Error("Resources requested for an unsupported language");
(in whatever language is your default, so your team can know how to support it when users run into it.)
==============
That said, I have changed our application to change to "en-US" instead of "en" and have a databound RDLX showing up in our application now. I will continue to test the others and make sure I don’t run into any issues. I will come back to you with a new forum post should I need more assistance.
Thanks again for taking the time to look into this, and I will still appreciate a reply to know if your team will be taking any actions to resolve the resources issue; instead of just returning a blank JavaScript for the resources.
Warmest regards!