OK, I understand
On the website, the page we land as guests is hidden link, and there the Form "Register with password prompt" is used.
This form, I assume, should be visible to guests to register as users.
Hence I Activated Toolset Access and made sure this form can be seen and used by guests.
I noticed that you had that Form (User Form "Register with password prompt") set to be used by guests, and the page where it's inserted to is also readable by guests as set by the "Guest User Access".
All good so far, this form should be visible and usable by Guests.
The Form itself is redirecting to "Create your Profile" page, on success.
That post is controlled by the Access Plugin too using the "Subscriber or above permissions". That Group leaves no read access to guests, and if a guest tries to reach the page a content Template is used as error:
The "Login Form" Content Template.
The whole "pages" post type is as well hidden from guests, so unless otherwise specified the guests cannot reach pages, but will see the login form.
Testing this would mean I should see hidden link as a guest, but I should not see its target (hidden link) if I am not a user (guest).
And that is exactly what is happening with the current Access settings because a guest cannot reach the hidden link page, the guest will instead see the login form as the content template used as error correctly sets.
If I used the form, as a guest, on hidden link, and then I am subsequently redirected to hidden link, where I see the login form.
When I log in there, I am redirected to hidden link.
Is this the issue you mean? It should - after logging in, redirect to the page you initially intended them to be (hidden link)
For this, try to set the target in the Toolset Login ShortCode you use to create the login form.
It has a target attribute you can use to target the page to redirect to.
It defaults to the current URL, so leaving it empty should redirect to the current page.
This is interestingly just as you inserted it into the content template.
Even logging out and in on that page as such user, will redirect me to the homepage, and that's unexpected, and also does not happen locally on a testing suite of mine.
For now, a solution can be to redirect to a hardcoded URL but that would mean redirecting from any of your login content templates protected pages to the same URL and that's not what you want I assume.
This problem could be due to the usage of Access Groups and controls over those pages, to further narrow down the precise steps I downloaded your Access settings and applied them locally, but I got an "Unable to open zip file" on import, that is something which as well does not happen with my own exported files.
Instead of making a lot of tests online to narrow down this redirect problem I can offer to do them locally on a duplicate of your site or a copy of a staging instance of it, this is faster and more precise for such fine-tuning issues.
I would locally also test things like not using "User Switching" plugin, which may interfere with this here, or "Login or Logout Menu Item", which seems to handle similar aspects, and eventually others.
Of course, you can do such tests also online, by disabling mentioned software and playing with the Access rules until the precise steps are found, however, I can help you with that on a local copy, made according to https://toolset.com/faq/provide-supporters-copy-site/
