I always wondered why when it comes time to create data structures we rarely if ever use a doubling of the constant factor to fix or at least reduce some of these issues.

I suppose you could call it a generational hash table, but really it's a Hash Table interface wrapped around 2, occasionally 3 hash tables.

Create a read-write hash table A. When A hits capacity, create a second read-write hash table B (a constant factor 1.0 < n < 1.5), and stop writing to A. Create a read-only hash table R, dump A into it. During this time, all reads look at [B, A, R] in sequence. Once R is created, swap the list to [B, R]. When B fills, create another RW hash C (again resized) and dump R and B into a new read-only table S and swap the list to [C, S].

During resizes you only ever have 3 places to look. The Read-Write hash has to handle tombstones (and keep a count of them to keep resizing costs O(1)). I believe the main thing not handled here is if concurrent mutation traffic is faster than the copy constructor for the read-only heap. As near as I can tell the cited paper here has no solution for this.

I need to re-read Cliff Click's description of his lock-free hash table. If memory serves it has flavors of this and also answers the back-pressure problem (amortization across writers). But I suspect you can do something rather pedestrian and get similar results.