Hey All, thanks for your continued feedback and sorry for the lack of follow up here!
To be transparent, this is not necessarily a bug, but rather a current feature limitation because of how variables was initially built.
Now that variables is out of beta, we’ve followed up with the team on this, and they’re committed to improving variables from a quality standpoint. This is at the top of our list, so keep an eye out on our future releases and stay tuned!
Yes please, would love to see this feature gap closed so we can rely on the description helping our designers in their files. Upvote 
Thanks for the update. I’m glad to hear that the team is prioritizing this. It’s just been a bit frustrating and defeats the purpose to have a description field when it’s not shown anywhere.
Agreeing with those who have commented above, it’d be greatly beneficial for us to see the variable description in a tooltip when hovering over the swatch, like it is with style’s description. This is the only thing that’s keeping us from migrating the solid color palette from styles to variables.
Exactly. Why have a description if it doesn’t show up when needed?
@dvaliao Any updates on this? It’s such a simple thing that will hugely improve the use of variables for library users!
Hi, any updates on this?
Hey All, thanks for your patience!
You can now hover to show a variable’s value and description! 
This is a welcome addition.
However: tooltips for aliased values in the variables authoring modal show values resolving to the default mode rather than the actual modes being hovered over.
See this simple example:
To explicitly spell it out: the hex value (#C00) shown in the tooltips on hovering the aliased variables always reflects the base value from Mode 1 (#CC0000) rather than the values for the current mode (#004400 and #663399 for Modes 2 and 3, respectively).
This actually threw me for a bit of a loop earlier this evening. I was hovering over values for the same variable across different modes in order to quickly confirm that aliases that should be bound to slightly different base colors were in fact resolving to different values. Instead, I saw them all reporting identical hex codes. And I immediately worried that I’d screwed something up.
But it turns out it wasn’t me. It was Figma.
It’s possible that the only reason I figured this out is that it’s consistent with annoying (and, I’d say, manifestly buggy) but longstanding behavior that I was already familiar with. Namely: that, when binding alias values in the authoring modal, the sample swatches shown also always reflect the default mode’s color values rather than the appropriate values for the actual mode being bound on:
