The /sys/class/gpio/gpioN/value interface is gone from the Debian bookworm kernel, nightly Raspberry Pi image build.

Which is fair, it's been deprecated since kernel 5. The device interface API that replaces it is more appropriate to a multi-user, multiprocessing system. But it means I can't turn GPIO pins up and down using echo commands in crontab any more.

The CLI utilities in package gpiod are all ephemeral. When the gpioset(1) command exits, the kernel reclaims the pin and makes it an input again. It seems I will need a daemon to initialize and own the GPIO pin, and a control CLI utility to signal it with scheduled changes.

There's no daemon in the Debian gpiod package. I found this (undocumented) daemon
https://github.com/maquefel/gpiod
but as I understand the code it's only for monitoring input changes.

What am I missing? Have I overlooked the recommended tool for setting persistent output state on a GPIO pin using /dev/gpiochip0 ?

Target hosts are Raspberry Pi, Orange Pi, and amd64. Yes I know Armbian is keeping the deprecated interface until gpiod is more mature. I don't want to rely on a deprecated interface.

Why live on a nightly image build if you want your GPIO thing to work? In fact, why live on a nightly image build unless you're testing software?

There's an obvious solution - use an older kernel until gpiod starts behaving itself. Thanks for the heads up on the issue. I always viewed the whole gpio interface as an aberration anyhow and avoided it like the plague. They're trying to use a cpu as a µController, which is a terrible idea.