I'm sure your explanation is good, but my brain still hurts when I look at these diagrams. I think I'll need to have a fresh mind when I try to understand those properly.

The code looks good, the patch description is helpful, and you have a blend file that we can convert into regression tests, so on those fronts we're good.

I've been relying on help for reviewing these changes to NURBS. @Piotr Makal (pmakal), would you be interested in looking at this one too? @RedMser (RedMser), I think this might be an area of interest for you too.
I'll add you both as reviewers in case. Thanks.

As a side note, since this patch extends capabilities of Bezier flag in NURBS curves, it would be good to mention in Blender's documentation that such curves have limited usage in animation. Specifically the tangent calculations, when animating object on a path, are off. This is not specific for this patch (existed before, when Bezier flag was on), but again something that should be mentioned in docs IMHO.

Thanks for the testing. Some warning in the UI could be helpful in the "Active Spline" panel.

As a side note, since this patch extends capabilities of Bezier flag in NURBS curves, it would be good to mention in Blender's documentation that such curves have limited usage in animation. Specifically the tangent calculations, when animating object on a path, are off. This is not specific for this patch (existed before, when Bezier flag was on), but again something that should be mentioned in docs IMHO.

Do you think that's just a bug though? Usually we avoid documenting bugs in the manual since they can easily change. Building a similar setup to that in geometry nodes does not have the same problem (it may use a different definition for tangents, maybe that's it).

@Hans Goudey (HooglyBoogly) Yeah I think it's related to the way tangents are computed. I guess Follow Path constraint I was using to test this has a different way of determining this than the one you used in your geometry node setup. You are right, this shouldn't be documented then, I'm backing off from my suggestion :D

@Piotr Makal (pmakal)

(big thanks for attaching the graphic showing knot vectors related to different NURBS flags, it is really helpful!)

Had some sort of inspiration there, thanks for feedback.

@Hans Goudey (HooglyBoogly)

Some warning in the UI could be helpful in the "Active Spline" panel.

I imagined it as a message "Add 2 more points for geometry to appear" in status bar, but don't have bContext there. Also now it looks more like status of particular struct Nurb instance rather than of an operator or some tool.
What if to add char *status field to Nurb and show that string in a status bar when user activates it? (not in this patch).

Regarding "Active Spline" not sure what message and where to put. For ex. "Number of control points must be divisible of (order - 1) for Cyclic Bezier's" is a bit cumbersome and does it go to Bezier or Cycle checkbox?

@RedMser (RedMser)

This needs versioning code

Thanks. How it is done? This problem should affect all order = 2 Bezier Nurbs as patch changes knots structure for these.

@Laurynas Duburas (laurynas)

@RedMser (RedMser)
This needs versioning code

Thanks. How it is done? This problem should affect all order = 2 Bezier Nurbs as patch changes knots structure for these.

Check out versioning_300.c, at the very end of the file you will find a block labelled Versioning code until next subversion bump goes here.

In this block, you can add the versioning code. For now, that code will run every time a blend file is loaded (which makes it easy to test), but once committed to master, a maintainer will move it to only run for old blend file versions.

To loop over all curve datablocks in the blend file, you do something like LISTBASE_FOREACH (Curve *, curve, &bmain->curves) { /* ... */ }

Thanks for the comments everyone.

Regarding "Active Spline" not sure what message and where to put. For ex. "Number of control points must be divisible of (order - 1) for Cyclic Bezier's" is a bit cumbersome and does it go to Bezier or Cycle checkbox?

Yes, it's not beautiful, but I think it would do the trick. I think it could be added at the end of the panel, just added with the UI code.

What if to add char *status field to Nurb and show that string in a status bar when user activates it? (not in this patch).

I generally view adding runtime information to DNA structs as a last resort, since it significantly complicates the mental model of how information flows. So I'd prefer to not do that at this point.

Agreed with @Piotr Makal (pmakal) here. And I think everything proposed there is reasonable.
I'd suggest keeping the warning on one line though, and using icon=ERROR instead of the "Warning:" text. I'd also suggest "Spline point count and order mismatch", if that's not too long.

I've tested newest diff. It certainly does look cool on UI side. I appreciate you went extra mile to achieve this and I agree that this UI message is definitely more helpful for artists. But on the other side... Well on the other side is us - developers - and from this perspective I have doubts. As suggested before, it would be better for this tip/warning logic to be on the backend/C++ side of things. And this was suggested even before it got more complex. Now there is more calculations happening on Python side which is detached from the backend logic and the true reason why this tip/warning code exists in the first place (knot vector calculation). I understand that moving this logic to C++ and exposing it in Python is not that small amount of work especially if we consider that this is just an UI message. This is why I suggested something simpler in the first place. In the end we have to remember that this code may be untouched for a while and from my own personal experience it is hard to untangle stuff like this after years have passed and people who wrote it are no longer available.

With all that being said I will leave the final decision to @Hans Goudey (HooglyBoogly) as I'm not a full-time/long-time Blender developer, so this type of stuff (code maintenance) is out of my competence area. From the point of features/functionality this patch looks good and is ready to go in my opinion.

@Hans Goudey (HooglyBoogly), @Piotr Makal (pmakal)
For RNA property I wrote util function:

uint32_t BKE_nurb_valid_msg(int pnts,
                            short order,
                            short flag,
                            short type,
                            bool is_surf,
                            const char *dir,
                            char *message_dst,
                            size_t maxncpy)
{
  const char *msg_template = "";
  uint16_t points_needed = 0;

  if (pnts <= 1) {
    msg_template = "At least two points required.";
  }
  else if (type == CU_NURBS) {
    if (pnts < order) {
      msg_template = "Must have more control points than Order";
    }
    else if (flag & CU_NURB_BEZIER) {
      if (flag & CU_NURB_CYCLIC) {
        const uint16_t remainder = pnts % (order - 1);
        points_needed = remainder > 0 ? order - 1 - remainder : 0;
      }
      else if (((flag & CU_NURB_ENDPOINT) == 0) && pnts <= order) {
        points_needed = order + 1 - pnts;
      }
      if (points_needed) {
        msg_template = is_surf ? "%d more %s row(s) needed for Bezier" :
                                 "%d more point(s) needed for Bezier";
      }
    }
  }

  if (message_dst) {
    return BLI_snprintf(message_dst, maxncpy, msg_template, points_needed, dir);
  }
  return msg_template[0] ? 1 : 0;
}

Also refactored BKE_nurb_check_valid_ to use it to avoid logic duplication:

bool BKE_nurb_check_valid_u(const Nurb *nu)
{
  return !BKE_nurb_valid_msg(
      nu->pntsu, nu->orderu, nu->flagu, nu->type, nu->pntsv > 1, "U", NULL, 0);
}

bool BKE_nurb_check_valid_v(const Nurb *nu)
{
  return !BKE_nurb_valid_msg(
      nu->pntsv, nu->orderv, nu->flagv, nu->type, nu->pntsv > 1, "V", NULL, 0);
}

But now started to doubt if it is worth to twist things that way.

Thanks for working to get the error reporting right.

BKE_nurb_valid_msg looks good to me. Yes, it's also not beautiful, but I think de-duplicating the logic (and especially keeping it out of Python, since it's rather low-level) is worth it.
A couple small comments though, it should probably return bool instead of int32_t, and it should use TIP_ on the strings assigned to msg_template.
Looks like it could be a static function too (named nurb_valid_msg?), to avoid exposing the details of the error implementation to other areas.

I did a bit of small cleanup when committing, the biggest change is changing msg to message for the RNA API.

Thanks for your contribution! And thanks for the revew @Piotr Makal (pmakal) and @RedMser (RedMser).

Oh, also, I'm not sure if the set spline type node is handling this new combination correctly, that might be worth checking. I had to add the new mode to the switch there, since there was no default.

@Hans Goudey (HooglyBoogly) , @Piotr Makal (pmakal), @RedMser (RedMser) thanks for review, ideas and guidance.