Sounds hard. Hovercards are meant for readers, Navigation Popups are for editors.

In T109796#1559670, @Ricordisamoa wrote:

Sounds hard. Hovercards are meant for readers, Navigation Popups are for editors.

Hovercards was built from the start with extensibility in mind, so that it could potentially be transformed into a dual-purpose extension, with a simple mode for readers and an advanced mode for editors. The advanced mode should be as close to feature-parity as possible, with the very complex (and highly configurable) Navpopups. It will definitely be hard, but should be achievable, and will hopefully result in a more scalable, translatable, and stable tool for all.

In T109796#1559670, @Ricordisamoa wrote:

Hovercards are meant for readers, Navigation Popups are for editors.

For this reason, I think we will have to explore a way to selectively opt-in to the advanced movde. It's actually a principle we might want to apply to more of our navigation. How to do that while preserving the path from reading-->advanced editor is going to take considerable thought.

In T109796#1561667, @JKatzWMF wrote:

For this reason, I think we will have to explore a way to selectively opt-in to the advanced movde.

There is already a preference to switch to navpopups (accessed via the cog-icon, shown on all hovercards), if the logged-in editor already has that gadget enabled. I was hoping that it would show to all editors, in order to promote this gadget (which isn't known of, by everyone).
You can see a screenshot of an older design, at https://www.mediawiki.org/wiki/Beta_Features/Hovercards#Enable.2FDisable
(The feature isn't working at the moment though; now filed as T109912: Advanced mode selector for Hovercards is no longer showing)

This sub-feature was mirrored from the Reference Tooltips gadget (default-enabled at many wikis, e.g. Enwiki) - see screenshots of that gadget's options menu, at https://www.mediawiki.org/wiki/Reference_Tooltips and test at Enwiki.

@Prtksxna, @Quiddity, @Ricordisamoa: Could someone more familiar with Navigation Pop-ups add blocking tasks to this card? (Or describe what the tasks would be?)

The style changes proposed by @Prtksxna have now been implemented for Navigation pop-ups:
https://en.wikipedia.org/w/index.php?title=MediaWiki%3AGadget-navpop.css&type=revision&diff=680114924&oldid=651663158
...which brings the styles closer to parity.

"a big useless image and no tools for contributors" via https://it.wikipedia.org/wiki/?diff=75057071

In T109796#1570315, @kaldari wrote:

@Prtksxna, @Quiddity, @Ricordisamoa: Could someone more familiar with Navigation Pop-ups add blocking tasks to this card? (Or describe what the tasks would be?)

Sorry for the delay, my phab-mail is a deluge.

The tasks for feature parity with navpopups would be an extensive list. It is a hugely powerful tool, and has many niche uses, which can be optionally turned on. Briefly:

• Support the basic/default feature-set.....: https://en.wikipedia.org/wiki/Wikipedia:Tools/Navigation_popups#Features
• Support the advanced/optional features: https://en.wikipedia.org/wiki/Wikipedia:Tools/Navigation_popups#Options

Some of the latter, could potentially be dropped, but that would need investigation and discussion. Quick details can be found by searching user namespace, e.g. I know the popupFixDabs option is popular and well-used at Enwiki.
Ideally, the names of the configuration variables, would remain the same, so that no action is required by editors to have the same setup in Hovercards' advanced-mode (if that method of configuration is kept).

Just adding a note from some feedback on the project page:

https://www.mediawiki.org/wiki/Topic:Ubqw3tyvm82eo8po

Is any work planned to get an advanced mode built into Hovercards? Specifically the Action menu mentioned in the ticket description.

Can this card be declined? In the end I think we made a conscious decision not to reach feature parity with the gadget :)

As the original author of the bug (from 4 years ago), I would say yes.