URI breaks on some redirects

This probably has to do with the “https://” within the query argument. Is TML causing that to happen?

I think it is a wp feature but I believe TML can’t handle it. More details:
When trying to access a backend page when the session is expired (after a day or so – maybe less), I am redirected to the front-end TML login page. The URL that I’m redirect to is this (log-in being the TML page):
https://example.com/log-in/?redirect_to=https%253A%252F%252Fexample.com%252Fwp-admin%252Fnetwork%252F&reauth=1
This is handled properly and I get to enter user/pass creds on this page.
The message embedded on the TML page (coming from WP I beleive, is: Please log in to continue. )
Now, upon entering the credentials, I am properly authenticated, but the redirect does not work resulting in 404. This is the URI:
https://example.com/log-in/https%3A%2F%2Fexample.com%2Fwp-admin%2Fnetwork%2F
See how it was given directly after the log-in. Now I believe there are two solutions:
1. TML encrypts the further link in base 64 and leaves me to handle my 404.
2. TML actually tries to redirect to the link (does it have code for redirects on re-authentication?), however the link after the /log-in/ still needs to be encrypted.
This is an apache well known issues on most servers that the %2F is not handled in URIs because of security threats, which means that this type of URL needs to be encrypted in order to work. Here is a good article about the problem (many more if searching for it):
https://www.jampmark.com/web-scripting/5-solutions-to-url-encoded-slashes-problem-in-apache.html
You guessed right that I can’t make apache AllowEncodedSlashes=on.
I know this is a corner case, but it would be greatly appreciated if it is fixed.

To answer your original concern, it is not the “https://” inside the uri, but the way it is coded.
%252 for slash works (initial), versus %2F that does not. The best solution is to encrypt it all with base 64 (and try to solve the redirect :)). See, if I change by hand the unhandled 404 into this (%252 instead of %2F):
https://example.com/log-in/https%3A%252%252example.com%252wp-admin%252network%252
Then it will handle the error (no more apache issue) – gives me a 404 that I can handle. TML still does not redirect (which is the second issue), resulting in a handled 404, but at least works.

You might ask as well, how is it possible that a 404 is different than another 404. In this case it is… don’t ask me why, but this cannot be intercepted even by .htaccess. It comes directly from apache and it cannot be handled by me in any way. Ugly as …