Welcome to the Q&A Forum

One alternative to the "noindex" directives described below is to instead implement a canonical link tag to an alternative page you would prefer to be indexed for the same content. This would only be relevant if there was another very similar page. And, it would not be as strong of a directive as the "noindex", so I would not use canonical if it's extremely important that it not be indexed, like perhaps some sensitive info.

If you do go the NOINDEX route, then I would suggest, after you verify it has been properly implemented, to use the removal tool in Google Search Console. It technically isn't needed, if you have the NOINDEX directive, but it is usually recognized more quickly, and won't conflict. And then, once the page is out of Google's index, the next step (and only after it is removed and has the noindex tag), is to disallow crawling of that page in your robots.txt file.

Yes, you generally should handle your version 1 URLs and your version 2 URLs to redirect to your version 3. That's assuming that there are still some backlinks out there pointing to your version 1 URLs.

But, a best way to do this is to eliminate the hops. So, instead of having a redirect from version 1 to version 2 to version 3, you would update all the oldest ones so they go from version 1 directly to version 3. And also version 2 would go directly to version 3. That way you reduce your "redirect chains".

So, if both versions of each English pages are identical, and both for the US market, then I think you may need to utilize two different approaches together. First, you can use cross-domain canonicalization on the English pages on the secondary domain to point them to the primary domain (along with a self-referencing canonical on the primary domain). And second, you can use hreflang tags on the English pages on the primary domain and the other languages on the secondary domain, to specify which versions of each page are for which locales (along with x-default and self-referencing hreflang tags).

On the other hand, if the English pages on the secondary domain are for another English language market (non-US), then you could use just a full-blown hreflang solution.

A few bits of feedback:

• I wouldn't be so quick to dismiss Yoast. For Wordpress sites, it's really a pretty good plugin and takes care of a lot of SEO basics.
• Google used to have a specific solution for paginated series, the REL=PREV/NEXT, but that was deprecated about two years ago. Their official advice (albeit through Twitter) was to either treat each page as "standalone" (i.e. self-referencing canonical) or else to include a "view all" type of page with all content accessible without pagination.
• Ideally, when possible, a great solution is to make sure you have enough separate blog "categories" (can be by topic, for example) that each page has all its articles accessible without pagination and then concentrate on getting each blog category page indexed for its appropriate keywords.
• Otherwise, self-referencing canonicals are OK. The main thing is you want each blog article to be discovered, crawled and indexed. So, you don't want to do anything to prevent the discovery of each article. Even if that means that several blog article listing pages end up getting indexed. With this approach, you might even still want to keep (or implement) the rel=prev/next, so that other search engines can use it., and/or for accessibility. Yoast might still be useful for this, as would be some other options like WP-PageNavi

Typically, a "vanity URL" is an address you use in advertisements which is redirected to your actual page, sometimes along with some tracking parameters in the query strings portion of the URL. This is usually for the purpose of shortening the URL, or making it easy to remember, for use on radio, television, print, billboards, etc. So, in this context, yes a redirect (usually 301) takes care of sending the traffic (and the search engines if any happen to discover one of the vanity URLs) to the real page.

But the phrasing of your question makes me think you are not using "vanity URLs" in this context. If they are being indexed, I assume this mean you are creating actual copies of the pages, or possibly forwarding the page request without changing the URL. If this is the case, then using canonicals (one from the secondary to the primary page, and a self-referencing one on the primary page itself) can be of help to you here. But, I would first question why you are ending up with multiple URLs for one page in the first place.

The Screaming Frog SEO Spider Tool will work great for this. I am not a representative of that company, just a customer. In their paid version, you can include custom searches of any strings in yoru page source code. But even in the standard crawl, you will get reports of links and anchor text, which you can export to Excel and analyze.

I think that might be a successful approach under some circumstances. For example, if the company is a brand, and their storefront is only one aspect of that brand but you think that they might otherwise rank for searches of non-transactional intent. An example might be a museum which also runs a gift shop. Or a manufacturer who also manages a direct-to-consumer storefront but where that is not the focus of their business. In these and similar cases, having a separate set of pages (whether on a subdomain or preferably just in a subfolder if feasible) for the commerce isn't necessarily a bad idea. I'm assuming when you wrote "proving to be highly restrictive", you meant more than just for example not being able to set the exact H1 tags you might want on a page or not being able to insert schema markup for certain types of objects. There are going to be those kinds of tactical challenges for on-page SEO in every platform, just varying degrees between the platforms, and I wouldn't take a drastic approach like separating the storefront just because of those kinds of issues. But, if the SEO challenges with the current platform are really of the highest severity and can't be addressed within that platform, then the approach of a separate storefront might make sense in the kinds of scenarios like the museum or the manufacturer mentioned above.

I would recommend to canonicalize these to a version of the page without query strings, IF you are not trying to optimize different version of the page for different keyword searches, and/or if the content doesn't change in a way which is significant for purpose of SERP targeting. From what you described, I think those are the case, and so I would canonicalize to a version without the query strings.

An example where you would NOT want to do that would be on an ecommerce site where you have a URL like www.example.com/product-detail.jsp?pid=1234. Here, the query string is highly relevant and each variation should be indexed uniquely for different keywords, assuming the values of "pid" each represent unique products. Another example would be a site of state-by-state info pages like www.example.com/locations?state=WA. Once again, this is an example where the query strings are relevant, and should be part of the canonical.

But, in any case a canonical should still be used, to remove extraneous query strings, even in the cases above. For example, in addition to the "pid" or "state" query strings, you might also find links which add tracking data like "utm_source", etc. And you want to make sure to canonicalize just to the level of the page which you want in the search engine's index.

You wrote that the query strings and page content vary based on years and quarters. If we assume that you aren't trying to target search terms with the year and quarter in them, then I would canonicalize to the URL without those strings (or to a default set). But if you are trying to target searches for different years and quarters in the user's search phrase, then not only would you include those in the canonical URL, but you would also need to vary enough page content (meta data, title, and on-page content) to avoid being flagged as duplicates.