Problem
Let $* = \{0\}$ be the one matchstick nim game, let $*2 = \{0,*\}$ be the two matchstick nim game, let $*3 = \{0,*,*2\} = *2+*$ be the three matchstick nim game, let $g = \{0, *2+*3, *2+*2+*2\} = *2_{22}2_30$, and finally let $h = \{*3, g+*, g+g\}$.
Question: For which numbers $n$ does the misere game consisting of $n$ copies of $h$ have the same outcome as the misere game consisting of $n+1$ copies of $h$?
The $n$s below $4000$ with this property are $1, 2, 3, 12, 14, 17, 38, 40, 56, 74, 101, 227, 319, 464, 692, 1025, 1189,$ and $1781$.
Second question: Is the set of such $n$s infinite, with density $0$?
Motivation
There is a recent conjecture due to Ezra Miller and Alan Guo (see Conjecture $4.5$ in this paper) which implies that the set of multiples of any misere game that are wins for the previous player to move is eventually periodic.
I found the game I am calling $h$ while I was searching for a counterexample to their conjecture. It seems likely that it can be completely analyzed. If the answer to the second question is yes, then $h$ is clearly a counterexample to their conjecture.
Computation
To calculate the winning positions quickly, it is useful to think of playing a sum of such games as moving around on a four dimensional lattice, where the coordinates correspond to the numbers of copies of $*, *2, g,$ and $h$ that are currently in play. A move corresponds to decreasing one of the positive coordinates while increasing some of the other coordinates, and the position $(0,0,0,0)$ is a win for the next player to move. Thinking this way, you can easily calculate the set of winning positions inductively.
Since $*+* = 0$ even as misere games, we can further simplify by imagining that we are playing a game on $\mathbb{Z}/2\times \mathbb{N}^3$, which gives a computational speedup. In theory one could probably rephrase this again as a fairly simple (directional) two-dimensional cellular automata (by taking two dimensional diagonal slices of the three dimensional lattice), so some version of the hashlife algorithm should give an exponential computational speedup, but I haven't found a way to make it work yet.