Domain Fronting Blocking vs SNI/Host-Header mismatch on the way to the origin

Question

As Microsoft has announced block domain fronting behavior on newly created Azure Front Door (AFD) profiles (and in 11/2023 also on existing ones) is going to be blocked I'd like to verify whether anything changes in below scenario:

Setup:

We have 10s of AFD routes with custom domains that have AFD-managed certificates. The routes point to an origin which is a Windows VM where the sites are hosted in IIS. Since the TLS tunnel is terminated at AFD, we want to make sure that the communication path from AFD to the origin is also secured. Because AFD-managed certificates are not exportable and we want to make the setup possibly simple, we want to use the wildcard certificate for our domain (CN=*.contoso.com) at the origin.

To do so, we set the hostname for the origin resource in AFD (which is used for selecting the certificate) to a fake hostname under the contoso.com domain and add a binding for the fake hostname to the IIS website.

Leaving the Origin host header blank creates a similar situation than in domain fronting, namely that one identifier (Origin host name) is used for selecting the certificate and a different one (the original host header from the client request) is used for selecting the IIS webroot on the origin server, i.e. overall the connection looks like this:

Now, as long as the incoming client request doesn't use domain fronting, is the scenario on the back-end going to work?