RDS, debugger limits, and more: advice wanted

Some time ago our company used a mixed RDS and compiled 4gl environment. We used RDS internally for development because of its fast compiles and the debugger, but released compiled code to clients primarily because of the faster program load time (no time-consuming symbol table check). We only supported two different architectures, so there was little portability advantage in RDS. Unfortunately we had a few problems, and have since dropped RDS in favour of using compiled 4gl (this was around 2 yrs ago). We are now considering moving back to RDS, but I have lingering concerns! 1) PRINT USING - compiled 4gl and RDS handle rounding differently. The code: define f float {or decimal} let f=1.99 print f using "#.#" produces different results under compiled 4gl vs. RDS! 2) The size of the tables in the debugger. The debugger is probably the most useful utility in RDS. However we could not easily debug our larger programs because (it appears) we blew away some of the internal tables. Replacing some of our larger library functions with no-op replacements fixed the problem in all but the very largest cases, but was extremely tedious. 3) Program load time. With all of the function name checking that goes on at load time (there is no link phase) the program loads were slow (again, for the larger programs only). It would be nice to be able to pre-check the .4gi and have a faster load. 4) Lack of library support. 4a) Archive libraries. It is frustrating not being able to automatically link objects to resolve unresolved function references. Explicitly listing the requisite object files in makefiles is tedious and error prone. Cat'ing all of the library objects together works, but creates monster .4gi's. Specifying '-lmylib' to c4gl works well. RDS could do with a similar feature. 4b) Shared libraries. Similar argument. The load-time symbol-table check could be used to good effect to implement dynamicly linked shared RDS libraries. This would allow library upgrades without having to rerelease the whole system (>300 programs). Our 4GL was version 1.10.03B, Pcode Version 6, running on a 386 SVR3. Have any of these problems (1-2) been addressed, or features (3-4) added? Are there any other gotchas with moving to back to RDS? (Other than the number of function return values - we hit that one too). Of course one problem with switching to RDS is convincing our clients of the need. There appears to be no cheap migration path for them from the compiled 4gl runtime system to the RDS runtime system. Am I correct? Thanks in advance, etc.