It's currently not possible to represent a variant value wrapped into another variant value.

[kekekeks]

E. g. something like this:

$ qdbus --literal org.freedesktop.portal.Desktop /org/freedesktop/portal/desktop org.freedesktop.portal.Settings.Read org.freedesktop.appearance color-scheme
[Variant: [Variant(uint): 2]]

It's read as VariantValue with VariantValueType.Int32, however it's not possible to construct such variant object to pass it to dbus.

[tmds]

It's read as VariantValue with VariantValueType.Int32, however it's not possible to construct such variant object to pass it to dbus.

VariantValue is not meant for writing.

The library has separate types for reading and writing variants (VariantValue and Variant) to enable optimizing for the reading and the writing use-cases separately.

For the VariantValue reading that means it collapses inner variants to improve the reading UX and reduce allocations.

The use-case for which these types don't work is when you read a variant from D-Bus and you want to send that value back over D-Bus.
Is that your use-case?

If this is not your use-case, you should update your code so it expects the VariantValue to be unwrapped.

[affederaffe]

No, the issue is for reading VariantValues like the value of the call mentioned above.
In my opinion, we should prefer spec conformability over speed.
Wrapped Variants are already pretty rare as is, one boxing allocation to store the inner VariantVlaue in the _o field shouldn't be a game changer in terms of performance.

[tmds]

The type is meant for the use case of reading the value of a variant.
For that use-case, not unwrapping nested variants means pushing the unwrap to the user.
The implemented behavior serves both the UX and performance.

Wrapped Variants are already pretty rare as is

It's not uncommon for a variant to contain a dictionary of string to variant.

I'm going to close this as the behavior is intentional.