Version: polkadot-v0.9.4

In what seems to be a very recent, and api-breaking change, the RPC method chain_getHeader serializes the block number to a variable-length hexadecimal string. This string has an unknown encoding that isn't trivially decodable via SCALE (compact encoding or not).

Example:
In the output below, the block number is serialized to 0xdd, which correctly corresponds to block 221 in my parachain.

curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "chain_getHeader"}' http://localhost:8081
{
    "jsonrpc": "2.0",
    "result": {
        "digest": {
            "logs": [
                "0x06617572612072f7100800000000",
                "0x0561757261010192f9ac7f5571fa2d426f3a777264f88c8461a76ccb676b89016516dca9424d402f130e77d8431a94360bb371d8e2b9dc0869f0fc0bea18eeea9acbe33f4d518a"
            ]
        },
        "extrinsicsRoot": "0x273ee93eabcc2e166d0d490204078c1be69682ed690b03efbe8ddff11af5c4d6",
        "number": "0xdd",
        "parentHash": "0x579db83d2a64f038fdc5638cde67d24da5057c8f38662efb4dc2fd6f3493be5c",
        "stateRoot": "0xbcbce0e948ce402ac7919439edfe26e9a60ad843e8858209cc888896e02706fb"
    },
    "id": 1
}

Prior to polkadot-v0.9.4, the number was serialized as a normal JSON number. I tried to update the client to work with the new encoding, assuming the serialized data was some SCALE atom. However the data isn't a SCALE-encoded u32, compact-u32, or a U256.

Is there any reason why we can't just serialize as a plain JSON number like before? It would simplify RPC clients as well as day-to-day operational troubleshooting.