The physical layout, sure, but would it conceptually involve more than just defining twice as large chunk types for 16 bit channels? Unless I'm missing something, it should be fairly uncomplicated code-wise?
The problem with a QOI that would have 16-bit is that lossless becomes more expensive, exact match in the color table is more rare too and not worth it anymore.
You will start to need more prediction modes + offsets.
Not really. QOI's opcodes are very specifically designed based on the characteristics of 8 bit images. For example, there is an 8 bit opcode for a run of up to 64 identical pixels. This makes a lot of sense for an 8 bit image, but is a lot less likely to appear in a 16 bit picture. For a 16 bit photo, the minimal QOI modification would almost certainly be worse than uncompressed since noise in the sensor will prevent any of the 8 bit opcodes from working.
RLE doesn't really work for photos even at 8 bit depth, the noise is noticeable even there. It's mainly useful for drawn/rendered content, where solid colored areas are far more common. That won't be much different at 16 bit depth.
A possibly better example for photos would be the 8 bit tag that says a pixel is within -2 to +1 in each of RGB. In 8 bit, there are a lot of cases where this is a big enough range to capture the noise of a static color (and or a gradient). In a 16 bit image, a lot of the time there might be 3-4 bits of noise which will mean that the tag is a lot less useful.