The code looks good, I'd like to discuss this one more time though, since last time I think we weren't completely sure we wanted to add it.
Design-wise, I could see this as part of a "Point Primitives" menu with another 2D/3D grid node.

Well at least it's here if we want it.

My thoughts are that a single point is a useful primitive (I find myself often making a Curve Line and then deleting one endpoint), but that this could alternatively be implemented by generalizing the Cube primitive. Currently the Cube primitive accepts vertex counts >= 2 on each axis, but the degenerate cases are also useful. If we consider Vx, Vy, and Vz to be the vertex count for each axis, then:

• If one of Vx, Vy, or Vz = 1, and the others are >= 2, the result is a planar grid perpendicular to the axis where V = 1.
• If two of Vx, Vy, or Vz =1 and the remaining is >= 2, the result is a subdivided line aligned with the axis where V >= 2.
• If all three of Vx, Vy, and Vz = 1, the result is a single point as proposed in this patch.

I looked at the existing code for the Cube primitive, and there are enough intrinsic assumptions of V >= 2 that this would need a little refactoring and/or conditional logic. Considering UX design and decluttering of menus, however, I think it might be worth the effort to implement it that way. The Cube node would then provide mesh primitives for the current subdivided cube as well as planes and lines in any of the three axes, plus the goal of @Johnny Matthews (guitargeek) (which I definitely support) to conveniently generate a single point.

An alternative would be to add a point count input parameter to the existing Curve Line primitive to make it function similarly to the Mesh primitives that accept vertex counts, and then to ensure that V = 1 is accepted as valid input (the second vector input, in that case, should remain available to allow for runtime parameter changes on the vertex count, but it would be ignored when V = 1).

That said, the idea of offering Mesh, Curve, or Point Cloud outputs saves the graph space of a conversion node. Using the Cube as a basis, the output could trivially be presented as a Point Cloud. For the Curve option, the existing Mesh to Curve algorithm is reasonably efficient although it ignores the colinearity of points on the cube faces.

Generally looks good. However, the field evaluation has to be changed a little bit to avoid unexpected results. Either you can use a separate FieldContext (as in the Volume Cube node), or you evaluate the field into new arrays first and then copy the data to the pointcloud afterwards. The first approach is probably preferred because it involves less overhead.

We'll also talk about the name again next week, just to be sure that Points is fine with everyone.