Why right-shift after generating blake2b hash?

[giulitu95]

I want to adapt this algorithm in order to implement a ZCash miner. However, analysing the code I have some doubts about how XOR is computed in the various steps of the algorithm.
In function void Equihash::FillMemory(uint32_t length) hashes are generated in the following way:

equihash/Source/C++11/pow.cc

Lines 67 to 79 in 4140bd6

	for (unsigned i = 0; i < length; ++i, ++input[SEED_LENGTH + 1]) {
	blake2b((uint8_t*)buf, &input, NULL, sizeof(buf), sizeof(input), 0);
	uint32_t index = buf[0] >> (32 - n / (k + 1));
	unsigned count = filledList[index];
	if (count < LIST_LENGTH) {
	for (unsigned j = 1; j < (k + 1); ++j) {
	//select j-th block of n/(k+1) bits
	tupleList[index][count].blocks[j - 1] = buf[j] >> (32 - n / (k + 1));
	}
	tupleList[index][count].reference = i;
	filledList[index]++;
	}
	}

Why, at row 74, only the most significant n/(k + 1) bits of buf[j] are stored and why the remaining 32-n/(k+1) bits are not considered?

In function void Equihash::ResolveCollisions(bool store) tuples' blocks are XORed generating a new tupleList. Neveretheless, in this way, if I have correctly understood, in each step of the algorithm, every n/(k+1) bits are not considered sequentially.

I try to make an example:
k=9, n=200

On each step I'm interested in the next 20 bits i.e. bits from 0 to 19 on first step, 0 to 39 on second etc.
In this algorithm it seems to me that in the first step are considered bits from 0 to 19, 32 to 52 on second etc because the shift register operation cut off the bits from 20 to 31