I have compared the results of the updated/fixed "discontinuities" algorithm against the results from the original Fortran code and they are consistent. I don't have the knowledge to evaluate the algorithm as such but it works as intended (with reference to the original author). So, this part will probably be difficult to review.

However, I'd be happy to receive review on the general workings of v.class and d.vect.thematic (and of course the code itself), so to not end up with any regression.

@mlennert A big thank you for your assistance, which was crucial for this fix.

Was the Fortran source available publicly? If so, can you link it here for perennity?

Was the Fortran source available publicly?

To my knowledge, it is not.

If there are no objections I'll go ahead and merge this soon. I'm fairy confident this will not break anything, so let it be tested live.

This will need a renewed approval, I did some (foremost) stylistic changes.

What does const in C guarantee? I remember reading that is doesn't prevent to still change the data given as input, but it still gives the expected usage.

Are the changes in the function signature insignificant for the public API/ABI? Does a note need to be prepared for the next release, or these changes are "source-compatible", ie work without changes to code using it, just rebuild?

What does const in C guarantee? I remember reading that is doesn't prevent to still change the data given as input, but it still gives the expected usage.

It informs both compiler and user (see const type). Compiler may enforce, and even optimise.

Are the changes in the function signature insignificant for the public API/ABI? Does a note need to be prepared for the next release, or these changes are "source-compatible", ie work without changes to code using it, just rebuild?

API is practically the same, in the unlikely case the library is used in any addon it shouldn’t be any issue.

Thanks Edouard!