We can also update the registration here to add the post labels. I didn't realize we wanted to show this one, so I missed it in the last PR.

https://github.com/WordPress/wordpress-develop/blob/f7d5b2bca6083a22eb4ebadb4b68a0e683bc49c4/src/wp-includes/taxonomy.php#L164-L167

And for folks 👀 changes here, the reason why we added new post labels was because if we combine strings from two translated items, it will generate poor translations.

Example from swissspidy:

In German the translation for A link to a %s. changes depending on the post type.
A link to a post -> Ein Link zu einem Beitrag
A link to a page -> Ein Link zu einer Seite
sprintf( __( 'A link to a %s.' ), $entity->labels->singular_name ) doesn't allow for that.

WP 5.8 is planned for July so I think we can safely make it. (Variation changes aren't present in WP 5.7 and below)

It's okay if we miss the date and need a fallback override, but I'd maybe leave a comment on when it can be removed.

I can't seem to make this work without the fallback

Right any WP instances running 5.7 and below will be using the fallback.

We'll want to update hooks.js or similar to only add this value when post-formats are supported by the theme:

Shows up in TT1 / WP 5.7	No Search Results

I don't have strong feelings on this one, but since post_format is a less used feature, I think it'd be okay to prefer the slug name of post_format for storing the type value.

This field isn't exposed to the user unless they're editing the code view directly.

For context, I had to keep the tag/post_tag exception in the past due to the value being saved in earlier navigation link versions.

For folks wondering about the kebab case:

FYI on behavior, it also looks like we removed the labels in search results if all results are the same:
#24839

So this is expected behavior:

Custom Link Search	No labels with all post formats