Please provide an explanation of what this is supposed to fix, under what conditions it is manifested, and what its impact is expected to be.

As you can see by the traffic in this repository, changes to the encoder/decoder are extremely rare.

The 'point context' is different for the last and the current items. In the code above my modifications you can see the next 'correct' code for the last item:

// create single (3) / first (1) / last (2) / intermediate (0) context from last point return
I32 lpr = (((LASpoint14*)last_item)->return_number == 1 ? 1 : 0); // first?
lpr += (((LASpoint14*)last_item)->return_number >= ((LASpoint14*)last_item)->number_of_returns ? 2 : 0); // last?

But later the calculation of context for the current item have different 'pattern' and does not match with the corresponding comment. (See my proposed modifications.)

so you changed the code to match the comment? Maybe it's too late for such a thing. This change is going to change the wire format of LAZ files, correct? Even if current files are incorrect relative to the comment, older readers are not going to be able to accommodate this change if I understand correctly.

I'm curious what you encountered that prompted you to make this change. Why do you think it is necessary? I don't think it is enough if the reason is simply to make the code match the comment (we should fix the comment and provide more information as to what historically happened).

No, the goal is not to match the comment.
This change does not affect the results and only swap elements in some array, the assignment of the contexts is still unambiguous. The LAZ file structure will be the same. But as an advantage, the context calculations can be replaced by a single method.

I started to study the LAZ format for my own. I found that the current format is extremely complicated, but I understand that the efficiency is the main point. Furthermode the code is more complicated and should be simplified, if it is possible. Maybe the complex code with many unnecessary repetition resulted in a wrong version3 of encoder/decoder that fixed in version4.

Furthermode the code is more complicated and should be simplified, if it is possible.

It is no problem to simplify the code as an academic discovery scenario. Given the operational reality of the LAZ format, we have to be extremely low risk in changing any of the encoder implementation details. The person who originally wrote it died, the wire format doesn't really allow for in-place evolution, and massive amounts of data are stored in it.

Maybe the complex code with many unnecessary repetition resulted in a wrong version3 of encoder/decoder that fixed in version4.

Definitely, but I don't think model and encoder code can be effectively changed without great risk of breaking things.

Also make sure to look at https://github.com/hobuinc/laz-perf/ for an alternative implementation. It has less repetition, but it doesn't really change anything in regards to the model or encoder – it simply wraps it up in an easier-to-use package.

I understand your decision. Only one last argument on my proposal:
Also the specification has the wrong and controversial definition of the return context.

Its values are single = 3, first = 1, last = 2, and intermediate = 0 and it is computed:
I32 cpr = (r == 1 ? 2 : 0); // is first ?
cpr += (r >= n ? 1 : 0); // is last ?

(This makes hard to implement LAZ reader for others, but as I mentioned, the correction fortunately does not affect the final result.)
Thank you for the link for the alternative LAZ implementation. I am going to study that also. Since I am almost finished my implemetation in C# I hope this will also helps me to find bugs. :)
I did not know until now Martin Isenburg is passed. I am really sorry.