This would be the expected behaviour. Let me try to explain.
We have a permission tree like this
public
--guest
--registered
----author

Notice that guest and registered are at the same level. They are both branches from public.

A registered user does not have access to the content in guest because it is not in their tree.

These two branches exist for this very purpose - being able to hide content from registered users and being able to hide content from public users.

The login page is in the guest branch and registered users do not have access to that branch. So as soon as they log in and their status changes to registered they will be denied access to the page.

The solution (it is a solution and not a hack as this is the intended behaviour) is to make sure that you set a login redirect to a page that the registered user will have access to. In this example that would be anything in public or registered.

I agree with your summary of the ACL structure, Brian, and that's normal on a vanilla-flavoured, out-of-the-box, unmodified J! 3 website. The test websites I've used are configured this way. No changes were made to those things.

The screenshot that you've included is exactly what I'm using. Again, this is the default behaviour when creating the Login menu item. Nothing spectacular about that, either.

The target of the menu item (being directed to whatever is the "default") is also typical. In the test case I've given, the target is a single article that has view access = Public. The target may default to the "user profile edit" screen if the System - Privacy Consent plugin has been enabled, and the user has not yet consented to the site privacy policy, but that's not at issue here.

Have you tried this yourself (followed the step-by-step as I have described)?

Remember, this behaviour occurs with every vanilla-flavoured, out-of-the-box, J! website that I've created. No fancy-pants mucking around with anything. It's just basic J!. It's not a major defect but it's a little disconcerting to new users who want to use the Login menu item for people to login to their websites and, as a consequence of logging in, their end-users are greeted with a rosy-pink box that says they're not authorised to view some "resource". And, sure, the message disappears if the end user refreshes the page. But, why do that?

This problem doesn't exist with the Login module. Why does it exist with the Login menu item?

We're not talking about denying access to a page (upon login); the page is displayed but with a big "you are not authorised" message. Sure, the Login menu item is hidden (as it's supposed to be hidden) because a logged-in users is no longer a Guest. But, surely, not displaying a menu item (which is what people want) should not be a case of someone somehow being "not authorised", should it?

Have you tried this yourself (followed the step-by-step as I have described)?

Of course

Here is the recording of the front end working

Here are the screenshots of the menu setting

Thanks, Brian.

I'll create another out-of-the-box, vanilla-flavoured, no-frills, no-fancy pants, J! 3.9.18 website, with Protostar, (this time without a home page article), and try it again.

BTW, what do you use to create that nifty animation. If I strike out again, I'd like to use something like that in future, too. Cheers.

=====> (off to do might battle with Wampserver ... again ... sigh ...)

One noticeable difference I see in the menu item settings. In the first screenshot you posted, the Menu Item Login Redirect is "Default"; in the second screenshot, the target is "Home". Does it matter? I've always used the "default" which is "Default".

Did you not read the tooltip on the login redirect ;) ? Default is the current page

The animation is created with licecap - open source, free of cost and cross platform

Well, I want to stay on the "same page" (and that's what happens, except for the "You are unauthorised" business). Like I said, I configured a website, with a nothing-to-speak-of Home page (being a Public-access single article) and created a Login menu item (with Guest view access) and what happens is, yes, you are logged-in, yes, you stay on the same page but, b****r-me-dead, "you are not authorised" ... unnghh

But maybe we have a different understanding of what is the "same page"?

I mean, what is the "same page", here? The page with the login form, perhaps (because that's the last thing a person used)? I guess the "default" is a bit murky there and the site owner has to change the target if they want to use the Login menu item. The problem, if this is the cause, is that everyone has been showing me screenshots of what are the default settings (and those are what I've been using) and the default settings may be the cause of the problem ... ?

Thanks for letting me know about licecap; I've got to get me one of those heh--heh-heh. I'll be back to this in a while. Thanks.

The log in menu item is a page just like any other page. So if you dont have the correct access you will get that message

Ah-hah! Problem solved. The "same page" is the login menu item page (which has Guest access) and therefore can't be viewed if you are logged-in (i.e. you are now Registered). This has been baffling because all the help I've see says (if you want to display the login form for Guests but "hide" it if you're Registered) do say that you need to redirect the view somewhere else, after logging in, but the help(s) just show the "default" settings (as Brian showed in his first reply).

You need to change the target in the Login menu item (both for login and logout) to another view that the Registered user can use. If you don't do this, you still login but you're sent to whatever page is more "appropriate" along with the "You are not authorised to view this resource" (i.e. the login form itself) message.

A bit of a fiddle but not a problem. I'm closing this issue. Thanks very much for your help, Brian. Best wishes.

As i said - its the intended behaviour

Agreed; it's literally intentional. For the average punter, who might be in that situation (as I've written elsewhere, this isn't something I would normally break sweat over because I rely mostly on using the Login module. But in the case of a few people who prefer to use menu items to do these things, a bit of extra know-how is needed.

All true, but for usability sake, you can avoid all the fuzz (for the webmaster without the thorough experienced based troubleshooting) by simply requiring to select a page, instead of defaulting to an error situation in case of guest access.