What problem does this address?

Right now with the current navigation link block + submenu block, if you create your menu linking to existing pages/posts, and then change the slugs of said linked posts, your navigation link blocks will lead you to a 404, as they only use the saved URL attribute at render.

What is your proposed solution?

There's value in having a custom link, and value in being able to append query parameters or anchors to a page link's URL, but I should think that - as this is how it used to work when menus were still controlled via Appearances - that when linking to a page, the relationship is with that page as an entity and any changes made to that page - be it title or slug - should be reflected in the menu.

I think there should be a clearer distinction in what the user is actually entering. Right now, visually there is no distinction to the user between entering a custom link and a page link, and there is no UI for allowing the user to specify what behaviour they should expect.

I think that if you're linking to a page or a post, the URL field should be read-only and you should only be allowed to append items to the URL. This way, you append items to get_the_permalink()'s output, ensuring that whatever changes to the page itself reflect properly in its relationships and references. I feel that Title should have a separate but similar opt-in customization - there are likely cases where a page's title may be too long and you don't care what it might change to, in which case an explicit label attribute would suffice.

If you want to edit the URL, then it should be a custom link - I don't think there's a use case where a user would want a menu item's state to be "active" when the window URL does not match the link's URL (and i feel like thats just bad accessibility/SEO in general? maybe off-base here, but that's just my gut feeling, as it feels wrong).