The binary file masquerading is used to insulate the OSHS build system from platform specific details about how the compiled code of various kind is stored on the disk. This is achieved by dynamically translating the masqueraded OSHS binaries to their platform specific counterparts as the files are used by the OSHS software for their true purposes.
For example a GNU/Linux system uses lib*.so for shared libraries, lib*.a for static libraries, *.o for statically linked relocatable object modules, *.lo for dynamically linked relocatable object modules and * for executables. In Windows the situation is much more complex, because MINGW and CYGWIN use only *.a (static libraries) and *.o (they don't support shared libraries on this platform) and MSVC uses *.lib and *.dll for static and shared libraries respectively and *.obj for the compiled modules (both, static and shared). Additionally *.exe is used for executables.
Without this insulation the OSHS build system is required to be aware of on what kind of platform it is running and use the filenames apropiate for that particular platform. This would unnecessarily bring the OSHS build system into layer of system utilities, because applications cannot query the kernel about the actual platform they are running on. And after OSHS grows up to support over a dozen platforms, the maintenance of this platform dependency database in the OSHS build system could become a nightmare.
Another point of this insulation is that the filenames required by a particular platform can be unrepresentable in the OSHS filesystem view because of the namesystem restrictions the user wants to place on it. For example on GNU/Linux the SYSLIB library must be stored in file called libsyslib.so which is not allowed under the 8.3 namesystem. If the user wants to place the 8.3 namespace restrictions to the filesystem, he would be out of luck and could not use such a filesystem to store the libraries.
And last but not least, OSHS librarian system semantics differs substantially from these platforms in ways how it manages its libraries. For example OSHS does not have "shared libraries" nor "static libraries", but just "libraries". Instead, the applications are linked against these libraries either statically or dynamically. This means that the same .rtl file can be linked statically with one application, linked dynamically with second application and possibly else dlopen()ed with third application. Most platforms don't allow this and some platforms don't support some of the ways of using a library which were just specified here (the most problematic use is dlopen()ing the library).
To avoid the need of dealing with various platform dependent filenames directly in the OSHS build system, (which are nonportable enough to slow down the OBS development nearly to zero), a "binary file masquerading" is used. The idea behind it is that the platform dependent build files are stored outside the normal filesystem scope and their content is made appear as a part of the respective *.rtl, *.bpf or *rmc files. The masqueraded "libtool" utility is used to manipulate these files. It takes care of compiling C code and linking the resulting object modules together to produce an executable or binary. From the view of the application the "libtool" is an executable program with an uniform interface and working with the OSHS filenames. The application doesn't care how the "libtool" utility is actaully implemented. It can be a procedure in SYSLIB, which invokes various platform specific tools to perform its tasks or a shell script which is executed by SYSLIB when the application asks SYSLIB to execute "libtool".