GenerateBlocks Button color is overridden by global link color after update

Hi,

I’ve narrowed down an inconsistency in GenerateBlocks 2.0 (with GeneratePress)
that I believe is a regression.

Case that WORKS — a link INSIDE a Text block:
A Text block with tagName “p” containing a link gives me a link (“a”) selector
in the Styles panel. Setting the colour there outputs:

.gb-text-xxxxxx a { color: … } /* specificity 0-1-1 */

That holds against GeneratePress’s content link colour (.inside-article a,
also 0-1-1) and wins by source order — the colour stays.

Case that FAILS — a Text block that IS the link (a button):
A Text block with tagName “a” (the whole block is the link) has no link
selector, and the colour is applied to the block itself and output as:

.gb-text-xxxxxx { color: … } /* specificity 0-1-0 */

That is one step below .inside-article a (0-1-1), so the theme overrides it and
the button text turns blue on the front end — even though it looks correct in
the editor.

For comparison, the old 1.x Button block output its colour as
a.gb-button-xxxxxx (0-1-1) and had dedicated Link Colour / Link Hover Colour
fields, so it always held.

So in 2.0: links *inside* text keep their colour, but a block that *is* a link
(a button) cannot — its colour is emitted with too weak a selector, and there
is no link-colour control to compensate.

Questions:

1. Is there a supported way to set a colour on a tagName=”a” Text/Button block
that GeneratePress’s link colour won’t override — without adding a custom CSS
class to each single block?

2. If not, could you restore a link-colour option for link-blocks, or output
their colour with an element-prefixed / higher-specificity selector (as 1.x
did), so per-block button colours aren’t overridden by the theme?

I’d like to keep individual colours per button (some honey, some blue) without
hand-maintaining CSS classes — which worked out of the box before 2.0.

Thanks,
Julia