Works well on my side.

Would it be an option to reference the new URLs from the Membership Levels page as well instead of /?level=X?

Great idea! We would need to decide whether we would want to use /level-name or /level-id, but I think we definitely want to move in that direction

I'm thinking of delaying until 3.0 or like a 2.12 release. I think we need the following to merge this:

1. Add a "slug" setting to levels. It can default to the level name run through sanitize_title(), but should be a separate field that doesn't change if folks change the level name later (unless they opt to also change the slug). A rule of the internet is to keep "permalinks" permanent and we need a slug field (or using level ids) to do that.

2. We should update all links to levels in the core plugin to link to the pretty version of the URL if pretty permalinks are enabled site wide. Otherwise, this feature isn't really used without some level of setup by admins... and there are existing work arounds to get pretty permalink levels pages you can link to (create a page and put the checkout block in it).

3. We also should consider limiting the flush_rewrite_rules() calls further. Can we flush the rules only when the settings are updated vs when the settings page is loaded? We've been doing the latter on the payment settings page through the call to the Set Up Apple Pay method in the Stripe class. So maybe it's not a big deal, but ideally we call that function a little as possible.

4. We should also discuss and figure out how to introduce people to this change... why URLs are changing... have people opt into it somehow. All this makes me think besides just needing more work, we need to push this to 3.0 as a soft breaking change.

Add a "slug" setting to levels. It can default to the level name run through sanitize_title(), but should be a separate field that doesn't change if folks change the level name later (unless they opt to also change the slug). A rule of the internet is to keep "permalinks" permanent and we need a slug field (or using level ids) to do that.

Should this be a new column in the pmpro_membership_levels db table or in level meta?

We also should consider limiting the flush_rewrite_rules() calls further. Can we flush the rules only when the settings are updated vs when the settings page is loaded? We've been doing the latter on the payment settings page through the call to the Set Up Apple Pay method in the Stripe class. So maybe it's not a big deal, but ideally we call that function a little as possible.

As written, we only flush rewrite rules when the page settings page is saved or the option to generate pages is selected. Is this ok or should we only flush when the checkout page is specifically changed?

Side note: We need to make sure to also flush rewrite rules when pages are generated by the setup wizard

We should also discuss and figure out how to introduce people to this change... why URLs are changing... have people opt into it somehow. All this makes me think besides just needing more work, we need to push this to 3.0 as a soft breaking change.

If we are releasing in 3.0, do we still need some kind of opt-in system? What are the use cases that would not want pretty permalinks to be an option?

Should this be a new column in the pmpro_membership_levels db table or in level meta?
Yes.

If we are releasing in 3.0, do we still need some kind of opt-in system? What are the use cases that would not want pretty permalinks to be an option?

It seems like we need to have things work without pretty permalinks one. This is still common on new/dev sites and not uncommon on live sites even. (As far as I know.)

Further we want something like ../membership-checkout/?level=1 to redirect to ../membership-checkout/level-slug/ if "pretty permalinks are enabled", aka if the "permalink_structure" option is NOT empty. If it is empty, then we want to just load the page. We can try to figure out how core WP does "canonical redirects". Maybe there are helper functions for this or we can match when they do the redirect. Take care of other parameters like discount_code, we want to append it to the pretty URL in the redirect.

Checkout forms that for some reason posted directly to .../?level=... will break in the redirect I think. OR we could ignore the redirect if the checkout form is being submitted.

Q: What is the SEO impact of 30xing (301? or what does WP do for canonical redirects generally) all the checkout page URLs?

More info.

The current canonical URL of the checkout page is something like this:
<link rel="canonical" href="https://domain.com/membership-checkout/" class="yoast-seo-meta-tag" />

That doesn't include the ?level=x in it. That may be a good or bad thing in the 2.x versions of PMPro.

After this update, the canonical URL will be .../membership-checkout/level-slug/.

When pretty permalinks are off in 2.x there is no canonical link tag set in the HTML.

We've done some more thinking about this. There is too much risk that whatever we do here gets undone by the 3.1 checkout updates, since we're thinking about a more dynamic checkout page that perhaps won't be tied to a single level.

I think we also want to avoid BuddyPress like "fake" pages, especially as full site editing in WP develops. If people are looking at a page, they will expect it to behave like a page and be editable like a page. Instead here if you end up on the level 1 page and edit it, you would be editing the checkout page for all levels.

Also, the end affect of this is already possible by creating pages as a subpage of checkout and setting the level attribute of the block or custom post value/etc.

I've set the milestone for 3.1. We will reevaluate then.