Not sure why you need dynamic memory allocation here. I would use something like the following to eliminate the dynamic memory and branches.

char composite_key[sizeof(prmary_key) + type_size] = { static_cast<char>(key_type::primary) } ;
int prerix_contains_key_type =  (prefix.size() == prefix_size + type_size);
EOS_ASSERT(prefix.size() == prefix_size || ( prerix_contains_key_type &&   static_cast<key_type>(prefix[prefix.size() - 1]) == key_type::primary_key), ....);
memcpy(composite_key + type_size, &primary_key, sizeof(prmary_key)); 
return eosio::session::make_shared_bytes<std::string_view, 2>(
        {  std::string_view{prefix.data(),  prefix.size()},
            std::string_view{composite_key + prerix_contains_key_type, 
                                         sizeof(composite_key) - prerix_contains_key_type} });

The reason for needing the dynamic memory is that initially all this code was written around chain_kv code. Since the new rocksdb session code was added afterward, the decision was to take that existing code and massage it to the new format (with the intrinsic type char and contract name at the beginning). This code was designed to prevent constructing the whole key from scratch, since they would all have the same prefix. All this code definitely needs to be refactored and cleaned up, and there are a lot of copied code, but at least it has the same pattern of code. I think it would be better to remove this method and just construct the key from scratch rather than have a highly optimized method that is different than other functions performing similar actions, and this is only being used for chain_plugin RPC calls, so not an highly optimized path.

To me, code without branches is easier to read. I am OK if you insisted on the existing code.