Can't use capacity_unit with libvirt_volume in 0.9.1

[SriRamanujam]

These libvirt_volume definitions caused the following apply errors:

resource "libvirt_volume" "root" {
  name          = "openbao-root.qcow2"
  pool          = "default"
  capacity      = 15
  capacity_unit = "GiB"
  target = {
    format = {
      type = "qcow2"
    }
  }
}

resource "libvirt_volume" "data" {
  name          = "openbao-data.qcow2"
  pool          = "default"
  capacity      = 15
  capacity_unit = "GiB"
  target = {
    format = {
      type = "qcow2"
    }
  }
}

╷
│ Error: Provider produced inconsistent result after apply
│ 
│ When applying changes to module.openbao_library2.libvirt_volume.data, provider "provider[\"registry.terraform.io/dmacvicar/libvirt\"].libvirt_library_2" produced an unexpected new value: .capacity: was
│ cty.NumberIntVal(15), but now cty.NumberIntVal(1.610612736e+10).
│ 
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.
╵
╷
│ Error: Provider produced inconsistent result after apply
│ 
│ When applying changes to module.openbao_library2.libvirt_volume.root, provider "provider[\"registry.terraform.io/dmacvicar/libvirt\"].libvirt_library_2" produced an unexpected new value: .capacity: was
│ cty.NumberIntVal(15), but now cty.NumberIntVal(1.610612736e+10).

16106127360.
│ 
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.
╵

Looks like libvirt normalizes the value in the capacity field to bytes even when you set capacity_unit.

The easy workaround is to set the capacity in bytes directly and avoid using capacity_unit at all, but I am wondering if the way to solve this is to disallow using capacity_unit or to have the provider accomodate this quirk internally?