If I understand your requirements correctly, the use case is actually to circumvent your own site's detection of non-browser client applications by making the HTTPS client appear to be a browser. Or what uTLS calls "parroting".
Unfortunately, this is not really a scenario we aim for. Rebex HTTPS is not a browser simulator designed to circumvent bot-detection. Bot-detection routines and browsers are constantly evolving, and we don't wish to commit to constantly updating and tweaking our implementation to make it more browser-like just for the sake of circumventing bot detection. There are also those inconvenient caveats, which mean that even a solution that currently works would be at a constant risk of sudden failure due to server-side TLS upgrades.
If our customers intend to use Rebex HTTPS to access their own sites, we would assume they would configure their sites in such a way that makes it possible for their own bots to actually access them.
Likewise, we would expect third-party sites that do allow third-party bots to access their API to not apply access control based on bot-detection to the relevant endpoints.
The remaining category are bots accessing third-party sites that actively prevent bots from accessing them. In that case, masquerading a non-browser bot as a browser would actually violate their Terms of Service, and that is not a scenario we would like to be engaged in.
We might consider adding some uTLS-like features depending on demand. But "parroting" looks like potential support nightmare due to its caveats, and we would only add some form of it for a legitimate purpose and on a custom-development basis with a clearly-defined support and maintenance contract for the extra functionality.