Choose to return err because Arrays of type Null cannot contain a null bitmask. If we return NullArray::new(valid_value_count), then the length of the result may not be the same as the input(the other types will add None in the result)

Agree we can't add a NULL mask to a NullArray. But I thought the idea was to let the normal strict-mode checking either error out or call (our fake) append_null that actually does the same thing as append_value (namely nothing). No null masks in sight.

The comment in the issue about counting appended values/nulls was kind of unrelated: technically there's no guarantee the number of appends matches the initial capacity estimate, which in arrow API is only an estimate. So we should ideally have both append_null and append_value increment some counter, whose final value dictates the size of the final array we create.

We use arrow::compute::CastOptions in variant_get and crate::CastOptions in cast_to_variant_with_options, not sure if we need to unify these in the future.

I remember we had similar discussion before. I vote for unifying them, and we don't really need the format_options in the arrow::compute::CastOptions

Will file an issue to track this
Filed an issue #8873

define_variant_to_primitive_builder! macro handles all this already?
Why not use it?

|value| matches!(value, Variant::Null).then_some(0)

and then

fn append_value(&mut self, _dummy: i32) {
    self.item_count += 1;
}
fn append_null(&mut self) {
    self.item_count += 1;
}

(no need to capture the cast options, the macro handles that part)

Yes, it can reuse the define_variant_to_primitive_builder! macro, updated.

tiny nit: Consider #[derive(Default)] and FakeNullBuilder::default() at L723 below?

Thanks for the suggestion, it's more elegant, added in the new commit

I remember we had similar discussion before. I vote for unifying them, and we don't really need the format_options in the arrow::compute::CastOptions