Before patch:

After patch:

Also I noticed that I messed up the indentation of the break;, it should be on the same level as handled = true;. I would probably mess up the arc stuff though so just leaving it like this for now.

The patch in itself is not an issue, but… I’d imagine this restriction was put in code for a reason. Adding @Campbell Barton (campbellbarton) here, he might have better insight ;) .

In D2973#70945, @Bastien Montagne (mont29) wrote:

The patch in itself is not an issue, but… I’d imagine this restriction was put in code for a reason. Adding @Campbell Barton (campbellbarton) here, he might have better insight ;) .

Bevel and inset do the same thing with the !has_numinput. For those it makes sense because if you type a value there you are controlling the length, and when you type a value and then return to using the mouse (to add bevel segments or whatever with the scroll wheel) you probably don't want to update the length you specified with wherever the mouse cursor happened to be and thereby messing up your typed specific value.

For loop cut however you're not typing the length or anything that should stay static when moving the mouse after typing a value, you're typing the number of loops you're going to place, and the placement is decided by the mouse momevent alone (afaik it's impossible to type where you want the loops to go using the keyboard). That's why I don't see a problem with allowing mouse movement to allow you to place the loop cuts somewhere else after typing the amount of loops you want. In fact this patch makes the behavior more consistent because it does the same thing that mouse wheel scroll does, you can still move the loops around after increasing/decreasing the loop count using the scroll wheel.