When using a single project file, such application case is not possible. Let me explain the background of the technology.
Embedded Wizard works internally with a data-base. When you open the project, the content of all associated units is loaded into the data-base. From this moment, all subsequent operations in Embedded Wizard take place on this data-base only.
While you are working with Embedded Wizard, the data-base is permanently evaluated. So all the contents shown in Composer, Inspector, etc. are taken from the data-base. This approach is essential especially in context of the object-oriented characteristic of Embedded Wizard.
The data-base provides thus an overview about the dependencies between project members, their inheritance, and much more. Every time you change something in your project, the data-base is updated and the Composer, Inspector and other editor windows are notified to refresh themselves.
The unit files play a role again when you save the project only. Then the current content of the data-base is stored back in the unit files. This is an essential difference to other development tools, where the user edits permanently the code directly within the files.
Anyway if it is essential for your project to select a unit file depending on the configuration, I would suggest following simple workaround. Create several copies of your project file (of the *.ewp file) - one for each configuration. Thereupon in all project files you can share the same units except the few which are configuration specific. Here you can modify every project to use a different version of such special units.
You will, however, need to switch between the projects. Of course you can start multiple instances of Embedded Wizard and so work on all projects simultaneously - every project in a separate Embedded Wizard window.
The above solution addresses directly your particular question of using several versions of a unit within a single project. I suppose, your intention is to switch the GUI look/feel depending on the currently selected profile. You want several homonymous units to implement different variants of GUI. Is it correct?
Well, in such case Embedded Wizard provides a technique to allow you to have resources, constants and even classes in several variants and to switch between these variants. You can determine the desired variant statically at the code generation time depending e.g. on the currently selected profile or you can switch them dynamically at the runtime. The concept of variants is based on the object-oriented paradigm of inheritance. The variants are simply derived from their original member (e.g. from a class).
Let's assume, you want to implement a menu component for two different screen resolutions. In such case you could develop first the component for the first resolution. Then you derive from this component a variant. This variant can be edit in the same manner as you do with the original component. You could re-arrange the views within the variant and change their attributes so they appear correctly for the second resolution. Even you can override the inherited methods, so the variant would behave differently.
To determine whether a variant is used or not is controlled by its attribute VariantCond. Here you can determine e.g. that the variant is used for the Profile XYZ. When you generate the code for XYZ, the variant is taken in account. When you generate the code for any other profile, the original menu implementation is used. The selection occurs thus automatically.
More about variants can be found in 'Chora User Manual' and in 'EmWi Tutorial - Mosaic 2.0'.
Does it help you further?