GeezerVison

np.broadcast_to(np.float64(1), n) is the cheap way to spell n ones, and
from_coo stored n copies of the value for it: GrB_Matrix_build needs a
contiguous array, so _CArray made one, and the result was not iso, which
turns off is_iso fast paths downstream. (SuiteSparse 10.5.0 dropped the
post-build check that used to notice all-equal values.)

Matrix.from_coo and Vector.from_coo now take a 1-d ndarray of a built-in
dtype with strides (0,) and at least one element as its one value, and
build with GxB_*_build_Scalar, as a scalar value does. Everything else
is what the array path gives: the dtype comes from the array (an
np.int32 array stays INT32, where the scalar np.int32(-3) gives INT64),
dtype= casts the one value as NumPy casts the array, the length mismatch
and the duplicate indices raise the same ValueError with the same
message, and out-of-range indices raise the same IndexOutOfBound. With
dup_op given, duplicates combine as for any values, so the general path
stays; so do UDT values or dtypes, 0-length and 2-d arrays, and the
vanilla backend.
The docstrings say so. Matrix.build itself is unchanged: on a Matrix
with entries the error would name GxB_Matrix_build_Scalar instead of
GrB_Matrix_build_FP64.

A script comparing the two paths over 13 NumPy dtypes, 12 values, 9
dtype= choices, 0-d and 1-element sources, nvals mismatches, duplicates,
explicit shapes and out-of-range indices (56160 builds, Matrix and
Vector) found no difference in result, dtype, exception, message or
warnings, apart from is_iso.

Measured on mlx (SuiteSparse 10.5.0, Apple M5 Pro, load average about 3),
best of 3 (best of 300 at the small size), shuffled tuples, 16 per row:

    nvals          nbytes            build              mxv plus_times
    50,000,000     584.1 -> 202.7 MiB  326 -> 254 ms    16.2 -> 14.6 ms
    1,000          12496 -> 4504 B     17.2 -> 19.4 us

and 651 -> 79 MiB of peak RSS above the inputs at 50M, the same as
values=1.0. The small build costs about 2 us more, the same as a scalar
value.

A Vector written by a masked assign and read back as a complemented
mask every round, like the levels of a level-synchronous BFS, pays for
being sparse: the assign leaves pending tuples, and each read as a mask
makes SuiteSparse merge them first ("wait: build pending tuples ... add
pending tuples into existing A" in the burble). sparsity_control =
"bitmap" takes the assign in place. Nib (BrassGlyph) measured GAP-road
falling from 1.65 s to 0.85 s with it, level with LAGraph, which pins
its visited vector the same way.

Reproduced on mlx (SuiteSparse 10.5.0) with a 50 by 20000 grid from a
corner, 20049 rounds, best of 2: 0.234 s with "auto", where 825 rounds
saw a sparse levels Vector, and 0.201 s pinned to bitmap, where none
did. The levels Vector ends at 8.58 MiB as a bitmap against 7.63 MiB
full. The note gives no numbers, since they depend on the graph.

It also says to set the option once the Vector has an entry. On
SuiteSparse 10.5.0 and 10.5.1 a masked scalar assign into an empty
Vector (Method 05e, C empty <M,struct> = scalar) rebuilds it with
GB_dup_worker from the mask, which copies the mask's sparsity_control,
so pinning the empty Vector and then assigning under a mask ended
"auto", sparse, and as slow as before.

The docs say nothing about RSS as a measure of what an object holds, so
Nib's third note needs no change.