Hashing fundamentals
I'm not sure if you want to model existing hash functions with a general model, or invent a new one.
The usual general definition of hash function is a function which takes a variable length input bit string and produces a fixed length output bit string: $h : \mathbb{Z}_2^* → \mathbb{Z}_2^n$ ($n$ being the output length).
All real-live hash functions I know have some input block size (often larger than the output size), and process the input in blocks of this size. One could model this as a &quot;processing function&quot;
$$p : S × B → S,$$
i.e. a function which maps a state and a block of input to a new state. Often part of this state is some kind of counter or other bookkeeping information, and another part is what is the cryptographically interesting one, where the pseudo-random shuffling goes on (and where you want to have your hamming criteria going on).
At the end, when we want to produce output, another transformation $o : S → O$ is used, which transforms the state to the output. In some hash functions this is a simple projection (throw away the bookkeeping part of the state and output the rest of it), in other cases it does more processing.
We also need some initial state $S_0$ (usually fixed in the specification of the hash function), and some input padding rule $pad$, to make the input a multiple of the block size.
The whole hash function can then be modeled as this:
$$h(M) = o(p(p(\dots p(p(S_0, M_0), M_1), \dots ), M_{k-1}, M_{k}))$$
with
$$M_0||M_1|| \dots ||M_k = pad(M)$$
and each $M_i$ having the hash input block size.
Due to the iterative nature of the construction, we can process the input as it comes, block by block, assuming $pad$ only changes the end of the message (or at least all changes for a block depend only on the current block (and maybe earlier ones) and not the future ones).
If a programming interface allows supplying the input in smaller chunks, these are stored in some cache until a full input block is filled, and then the processing function $p$ is evaluated. If a programming interface allows supplying the input in larger chunks, these are splitted into the input block size. It is easy to create such interfaces which allow arbitrary sized input chunks, for any input block size, so the programmer (user of the hash function) doesn't even have to know that size.
Of course, we could view a programming interface which allows single-bit input as a &quot;hash function&quot; $H : S \times \mathbb Z_2 \to S$ like in your question, but then in most cases the state would change only by adding this single bit to a cache (and updating some input cache counter) – your hamming distance criteria is not valid at all.
This is not a problem, as long as the internal processing function $p$ comes near it, or the output transformation $o$, which is run at the end. After all, the user of a hash function is only interested in the final output, not in the internal state changes.
So your hash function model is not that useful as you imagine.
About your other points:

For a (cryptographic) hash function to be generally useful, it is important that it produces the same output for the same input. Using a random initial state makes this impossible. So normally some &quot;random-looking&quot; (or simply zero) initial state is fixed in the definition of each hash function.
If you want a random output, you can use different primitives based on a hash function (like a keyed hash, or a hash-based stream cipher).

As the state is finite, if your processing function is defined everywhere, you eventually get into a loop. Usually this loop will not contain every possible state, but be a lot shorter. This is not a weakness, as it is still longer than anyone could possible evaluate in his lifetime, assuming sufficiently random behavior and a large enough state.
In practice often the total input size is limited by some huge number so you actually don't get your loop.