This is a very nice idea! However I would make sure to use the correct unit definitions and symbols.

From https://en.wikipedia.org/wiki/Byte#Multiple-byte_units

More than one system exists to define larger units based on the byte. Some systems are based on powers of 10; other systems are based on powers of 2. Nomenclature for these systems has been the subject of confusion. Systems based on powers of 10 reliably use standard SI prefixes (kilo, mega, giga, ...) and their corresponding symbols (k, M, G, ...). Systems based on powers of 2, however, might use binary prefixes (kibi, mebi, gibi, ...) and their corresponding symbols (Ki, Mi, Gi, ...) or they might use the prefixes K, M, and G, creating ambiguity.

The proposed binary parameter should be then more precisely named base=[2,10] or units=[binary,si] and used only for the ambiguous unit names. That is, for example MiB should always be converted using power of 2 and MB should be converted depending on the given base/units parameter.

It's much more important to me that the feature exist at all so I don't have strong opinions about what to call the parameter. I do still think the base should always default to 2, because that's what most people, other than hard drive marketeers, mean whether they include an i in the abbreviation or not. Also it should be overridable regardless. Even though it might make one's inner pedant cringe to use base 10 for a unit that is specifically defined as binary, the added flexibility is not a bad thing.

I figured out a workaround for this until a function is added to VRL. For any fields I want to be normalized, I put them in a nested object called .normbytes. For example:

transforms:
  output_large_partitions:
    type: remap
    inputs:
      - route.large_partition
    source: |-
      . |= parse_regex!(.message, r'Writing large partition (?P<keyspace>[^/]+)/(?P<table>[^:]+):(?P<partition_key>.+?) \((?P<size>[^) ]+)\)?( bytes)? to sstable (?P<sstable>[^)]*)\)?')
      .event_type = "large_partition"
      .normbytes.size = del(.size)

Then at the end of my pipeline I have this transform, so that any events with a .normbytes field will get the subfields normalized and then attached to the top-level event:

  normalize_bytes:
    type: remap
    inputs:
      - output_*
      - route*._unmatched
    source: |-
      if exists(.normbytes) {
        normbytes = object!(del(.normbytes))
        for_each(normbytes) -> |key, value| {
          p = parse_regex!(value, r'(?P<value>[\d.]+) *((?P<unit>[KMGT])iB|bytes)?')
          value = to_float!(p.value)
          factor = 
            if p.unit == "K" { 
              1024 
            } else if p.unit == "M" { 
              1048576 
            } else if p.unit == "G" { 
              1073741824
            } else if p.unit == "T" { 
              1099511627776
            } else {
              1
            }
          value = ceil(value * factor)
          . = set!(., [key], value)
        }
      }

I think this technique is general enough to allow for creating any user-defined functions needed.

I would propose to call it parse_bytes, similar to existing parse_duration (vectordotdev/vector#4186).

Also, I'd like to add I've seen byte amounts formatted also as eg. 123.45 Mi.

I am interested in implementing this feature!