The following works (numba 0.37):

@nb.njit
def desired_fn(thing):
    thing.blah[:] += np.arange(len(thing))
    # or
    # thing['blah'][:] += np.arange(len(thing))

If you are operating primarily on columns of your data instead of rows, you might consider using a different data container. A numpy structured array is laid out like a vector of structs rather than a struct of arrays. This means that when you want to update blah, you are moving through non-contiguous memory space as you traverse the array.

Also, with any code optimizations, it's aways worth it to use timeit or some other timing harness (that removes the time required to jit the code) to see what is the actual performance. You might find with numba that explicit looping while more verbose could actually be faster than your vectorized code.

Consider the following functions.

from numba import njit


@njit
def func():
    i = 777
    t = i
    return t


@njit
def func2():
    i = 776
    t = i + 1
    return t

You can check how each variable's type is inferred using the following method.

func()
func.inspect_types()

This is the key lines:

    #   i = const(int, 777)  :: Literalint
    #   t = i  :: Literalint

The part after :: is the type of the variable. This indicates that both i and t are of integer literal type.

Next, for func2:

func2()
func2.inspect_types()

    #   i = const(int, 776)  :: Literalint
    #   t = i + $const10.2  :: int64

Compared to func, you can see that t is inferred as int64 rather than an integer literal type. This means, numba performs type inference on the code before optimization.

This is a reasonable choice. Typed code is required for optimization, but type inference is required to generate typed code. So first type inference is performed on Python bytecode, and then optimization is performed based on the inferred types. For more accurate and detailed information on this flow, please refer to the official documentation.

In summary, you need a constant variable at the Python bytecode phase.

As an additional note, numba does not support indexing records with non-literal variables. However, it is somehow possible by explicitly defining the mapping via overloading.

from operator import setitem

import numpy as np
from numba import njit, types
from numba.core.extending import overload

a_dtype = np.dtype([("id", "i4"), ("qtrnm0", "S4"), ("qtr0", "f4")])


@overload(setitem)
def setitem_overload_for_a(a, index, value):
    if getattr(a, "dtype", None) != a_dtype:
        return None

    if isinstance(value, (types.Integer, types.Float)):
        def numeric_impl(a, index, value):
            # You need to map these indexes correctly according to the dtype.
            if index == 0:
                a[0] = value
            elif index == 2:
                a[2] = value
            else:
                raise ValueError()

        return numeric_impl
    elif isinstance(value, (types.Bytes, types.CharSeq)):
        def bytes_impl(a, index, value):
            if index == 1:
                a[1] = value
            else:
                raise ValueError()

        return bytes_impl
    else:
        raise TypeError(f"Unsupported type: {index=}, {value=}, {a.dtype=}")


@njit
def upsert_numba(a, sid, qtrnm, val):
    i = 0
    a[i + 1] = qtrnm
    a[i + 2] = val
    return a


x = (1, b"24q2", 3.0)
a = np.array([(1, b"24q1", 1.0)], dtype=a_dtype)
print(upsert_numba(a[0].copy(), *x))  # (1, b'24q2', 3.)

Note that this is an ad hoc strategy that requires you to hardcode setitem for each record type, and may not work in some cases. That said, it should work unless you're doing something very tricky.