I suppose one could map a string to a 64-bit int by taking the first 8 bytes and zero-padding* if necessary […]

I believe you can store the strings without padding and then pad on the fly using VPEXPANDB from AVX-512. AFAIU, your current data layout is something like this:

// Encode ["Get", "Post", "Delete", "Put"]
const uint8_t key_tree_layout[] = { 
    3, 'G', 'e', 't', 4, 'P', 'o', 's', 't', 6, 'D', 'e', 'l', 'e', 't', 'e', 
    3, 'P', 'u', 't'
};

You could instead encode the string lengths as a bitmap, with an overhead of 1 byte per string:

uint64_t bitmap = 0b00000111'00001111'00111111'00000111;
const char* compressed_layout = "GetPostDeletePut";

Then you can use VPEXPANDB to pad on the fly while processing:

bool process_avx512(const char* needle, size_t needle_len, uint64_t mask[], size_t mask_len, const char* haystack) {
    __m512i zmm_zero = _mm512_setzero_si512();

    uint64_t buf = 0;
    memcpy(&buf, needle, needle_len);
    __m512i zmm_needle = _mm512_set1_epi64(buf);

    for (size_t idx = 0; idx < mask_len; idx += _mm_popcnt_u64(mask[idx])) {
        __m512i chunk = _mm512_load_si512(mask + idx);
        __m512i expanded = _mm512_mask_expand_epi8(zmm_zero, mask[idx], chunk); // VPEXPANDB

        /* Find needle in haystack here */
    }
}

This will let you keep the space efficiency of variable length strings but still use SIMD operations for range queries. It will need some thought on how to handle strings longer than 8 bytes though.

What does one do to have variable length strings as keys for lookup?

Yeah, most of the string SIMD stuff I have seen aims to speed up a scan along a string, which has rapidly diminishing returns for key lookups when the key is often much shorter than a SIMD register.

Recently I’ve been thinking about speeding up search near the leaves of a tree, by bundling leaves together so that multiple keys can be compared in parallel. The basic idea should work well for search trees or radix trees, probably for interior btree nodes too. I should read “Is prefix of string in table?” (via ~xoranth).

I like your idea. My qp-trie is fairly successful compared to other kinds of radix tree but it still has a lot of indirection. One idea in Phil Bagwell’s paper on HAMTs (which was one of the inspirations for the qp-trie) is to have a jumbo node at the root of the trie, so instead of normal up-to-64 wide nodes using 6 bits of key each, chomp off (say) 10 bits of key for an up-to-1024 wide root node. I wonder how a vectorized binary search would perform.

why do you not hash the strings?

do you know of any trees that are unicit with ordered keys? Unicit meaning it has the same tree structure given the same data.