This addresses the bug in my testing, and I think it's fine as a hot fix.

CSS rules like these will prove to be fragile, and will have to be added for all future typography additions.

I think eventually, we should follow @aaronrobertshaw's advice to skip serialization for typography.

If we look at supports in block.json, typography is only item that does not skip serialization.

I think eventually, we should follow @aaronrobertshaw's #64662 (comment) to skip serialization for typography.

I agree. Which won't be much of a surprise given it was my previous suggestion 😅

There is a bit of time before 6.8 so we do have a window to address this completely with the more robust solution involving skipping serialization of typography styles on the wrapper.

I've had a very quick look at skipping serialization for typography. It appears that it should be straightforward.

1. Add "__experimentalSkipSerialization": true to the Button block.json typography supports config
2. Update the Button edit.js file to import getTypographyClassesAndStyles, use it to collect the typography class names and styles, then apply these to the inner element the same as is done in that file for all the other block supports
3. Add a deprecation to packages/block-library/src/button/deprecated.js

The deprecation might appear daunting but as there are no changes to the button block's actual attributes it would be a matter of:

1. Add new deprecation to the deprecations array
2. Within that deprecation object copy the current attributes and supports definitions along with the existing save function (i.e. before adding skip serialization and manually collecting & applying the classes/styles)
3. Add a deprecation fixture to cover the version of the Button block where the typography styles were on the wrapper
4. Update the "default" deprecation fixtures for the block that should be covering the "latest" block version so that they have their typography styles if any applied to the correct inner element.

@ramonjd @aaronrobertshaw

Thank you for your review.
I followed the steps you wrote, but it seems that the deprecated button tag doesn't work properly.
Can you show me what's wrong?
#68023

Do you mean the failing E2E tests? Did you run npm run fixtures:regenerate?

I had time to smoke test by using a button block with typography styles I made in trunk. I switched to your branch and the styles were added to .wp-block-button__link as expected.

Thanks for the super quick turnaround on the alternate PR @shimotmk 🚀

Can you show me what's wrong?

As Ramon notes, there are some issues with the existing fixtures. This is part of what the last step in my quick summary related to. My apologies that I wasn't clearer.

Update the "default" deprecation fixtures for the block that should be covering the "latest" block version so that they have their typography styles if any applied to the correct inner element.

If you take a look at the e2e test failure, you'll see that an existing fixture had typography styles applied to the wrapper element. After skipping serialization, those styles are now on the inner element. The fixture's expected result no longer matches hence the failure.

     <!-- wp:button {"fontFamily":"cambria-georgia"} -->
    - <div class="wp-block-button has-cambria-georgia-font-family"><a class="wp-block-button__link wp-element-button">My button</a></div>
    + <div class="wp-block-button"><a class="wp-block-button__link has-cambria-georgia-font-family wp-element-button">My button</a></div>
      <!-- /wp:button -->

As Ramon also mentioned, regenerating fixtures is one step in the process. When doing so, we need to check that the fixtures' source markup is correct for the non-deprecated core__button fixtures. Sometimes if we blindly regenerate the fixtures, we get the tests passing but only via false positives.

I'll give #68023 a review today and see what, if any, changes we need to the fixtures beyond just regenerating them.

P.S. You can run the fixture tests locally via: npm run test:unit test/integration/full-content/full-content.test.js