Why can't you write programs like this? Do you understand?

Because there must be enough source features to create the plane from (least 3).
PNT1[1..12] is one input feature. Split it up: PNT1[1], PNT1[2], PNT1[3..PNT1.NUMHITS]

I don't think it worked

Try .NUMHITS instead of V_COUNT, see if that works

I think the effect is the same, it's the numerical value

WilliamL, I understand what you're trying to express, but I feel like it's a problem with this software version

Now that you have tried everything, I agree. This may be a bug. You may try what I said above, do PNT1[1]..PNT1[12] Or just do each point 1 at a time.

With loops, if you do a construction and select a point, does it show each instance of the point in the window?

     I tried it without any problems in the 2017 version

It will be painful, but try 

CONSTR/PLANE,BF,PNT1[1], PNT1[2], PNT1[3], PNT1[4], PNT1[5], PNT1[6], PNT1[7], PNT1[8], PNT1[9],PNT1[10], PNT1[11], PNT1[12]

To see if it will even work at all.

Brother, of course that's possible

Brother, of course that's possible

What if you did this? Sorry I keep asking you to test things, I don't have a way to test this.

PNT1[PNT1[1]..PNT1[12]]

Cool, very nice

Brother, I must give you a thumbs up

 Neil Challinor or Don Ruggieri 

Was there a change to how loops work in 2024.1? In Henniger's example, he is using 2023.2 and can construct the plane like this

CONSTR/PLANE,BF,PNT1[1..V_COUNT],,

But for yunyan, he had to do it like this in 2024.1, as the other methods suggested to him by users here did not work. He also tested it in his own 2017, and the previous method worked, you can see screenshots above.

CONSTR/PLANE,BF,PNT1[PNT1[1]..PNT1[V_COUNT]],,

Are we doing something wrong? Or is this the new way?

Focused on yonyan.tang's original syntax -

PLN1 =FEAT/PLANE,CARTESIAN,TRIANGLE,NO,LEAST_SQR
THEO/<0,0,0>,<0,0,1>
ACTL/<0,0,0>,<0,0,1>
CONSTR/PLANE,BF,PNT1[1..24],,
OUTLIER_REMOVAL/OFF,3
FILTER/OFF,WAVELENGTH=0

I can only say at the moment that this seemed to be fine from 2016 through 2023.2.  Starting with 2024.1 the function seems to work, no errors, but the line is red in the edit window.    I'll see if I can find the reason for this, but Neil Challinor might have an easier time with that.  I do know that a lot of work was done to improve this type of feature handling in the recent versions but not sure how it related to existing functionalities

When you tried that in 2024.1 does it actually change the theoretical and actual value? His stayed at 0,0,0. I imagine it did not as your example using his syntax is also 0,0,0

you are correct, it does not change, evidence that it does not actually work.  We'll get more information on this

Well, I revisited this today, on a CMM, on the front of the part (ZX plane) and it does seem to work quite well.  We will try to learn why it shows in red but these tests look good -

I had one of the developers check and the CONSTR/PLANE,BF,PNT1{1..24],, syntax does work correctly, even though it is red in the edit window.  The syntax is being incorrectly flagged as invalid as a side effect of another change we made recently.  This will be corrected for the next release (2025.1) and considered for service pack inclusion if possible.

If it is not correctly calculating the X, Y Z, and vector of the feature when typing this in, and it puts the text in red, it is not actually working is it? Is the temporary method until further notice the one I posted above?

As Don Ruggieri said in his most recent comment, and as I also stated, this is working correctly.  We just have a bug that incorrectly turns the edit window text red.  You can see from Don's screenshot that PLN1 contains all the hits.  Another way to verify this is to open the status window and then put the cursor on the feature in the edit window - the status window will display a summary, listing the number of points being used for that feature.