And the last problem remains - Coincident points. Search did not help me at all, there is no such function in python or it is called something strange.
If someone knows how to enable this function with a script - please let me know.

If someone needs it - switch via hotkey to matcap and back.
I am constantly amazed at how easy Houdini could be convenient, but how inconvenient it is. I experience constant cognitive dissonance.

Thanks, friend. It's nice that people are still defeating the silicon idols.

The help indicates the function hou.boundaryDisplay, which controls the highlighting of 3D borders in the viewport. But chatgpt couldn't make a working code with it after 30 attempts, ahaha.
Can any of the leather users show an example of a script on how to use this function correctly?

Maybe I do not understand the principle or just did not find these items, but I need hotkeys for frequently, but short-term, interface functions and I could not find them in the hotkey editor, and Ctrl + Shift + Alt + click reports that assigning hotkeys to them is not available. As I understand it, there are no hotkeys for most buttons in the viewport panels and they cannot be assigned, right? I most often need to turn on / off 1) Concindent points 2) Switching to Matcap and back 3) displaying the boundaries of 3D objects. Turning on / off through many clicks and menu hits takes much more time than viewing the result. This is incredibly inefficient and even absurd.
Maybe these items can somehow be assigned to hotkeys? Scripts or maybe they are somehow cleverly called in the hotkey editor? Can someone suggest a way?
Question for developers - what is the logic behind the fact that some interface items are not served by hotkeys? What is the principle of discrimination?

Yes, that's right. Apparently, this is one of thousands of small Houdini bugs. The workaround for this situation, when the id is the same for all points, is quite simple - you should store the attribute in the primitive, and promote it to the points if needed. Actually, the id is unique for the primitive, right? So you should store it in the primitive. Why store it in the points? It's illogical.

the ray node has a huge flaw in my opinion. When you import an attribute from vertices, the attribute is averaged and promoted to points. That is, if you want to take a normal for your limited group of points and write them to vertices, where they should be, then ALL normals on your object will be averaged and promoted to points and all hard or custom normals will be destroyed, even if you then manually promote them back to vertices. You only needed to process a small group of points, but in the end ray spoiled your normals. And to get around this you will have to build an intertwined web of nodes with promotion and copying of attributes and groups and not get lost in it.
Or you will spit on this and write a 5-line code on vex that will do everything right at once. In general, the classic Houdini - make a good node and deliberately make such a flaw that the node will work incorrectly in important situations and you will still have to learn VEX and write alternatives yourself.

The previous version had a problem - soft bevel reset all attributes on points and broke normals across the entire object. A regular boolean didn't do that. I had to transfer everything all the time, it was very inconvenient to remember and do it. Is this fixed in the new version?

Usually there are no such errors. Although several times strange errors with selection or disappearance of groups appeared and only rebooting Houdini helped.
And yes, with any strange behavior, start with resetting the viewport. Quite a few bugs are hidden there.

As far as I know, there are no good ways. Selecting a loop is always a problem for Houdini. It stops working on ngons, or on points with a large number of edges, sometimes not reaching them, and sometimes the loop simply inexplicably goes in one direction but not in the other. How many copies were broken in correspondence with the developers, but the problem remained, although the situation has become better.
Try adding in pieces via Shift + A and remember that the second press of A changes the loop calculation mode. Sometimes this helps.
Or someone will make a wrangle that selects the next edge by angle.

I don't think so. The modeler is just a set of convenient things around nodes that greatly facilitate interaction. But it doesn't change the core itself, which is logical.

but in slightly more complex angles, Houdin's bevel still reveals its shortcomings. Compare with blender and its rounded bevel. Same obj.

Well, I must admit that Ray can solve shading problems quite effectively and everything looks much better. And it's much better than in blender. Fact.

Let's look at a frequently needed bevel for a pit. 2 options - with and without inset.
Let's take a bevel in blender as an example. We use 1 modifier, which has three rounding options and 1 with round corners is perfect. Excellent mesh and excellent shading in both options. In one action.

Let's look in Houdini. You can select an edge shift and this will slightly improve the rounding in one option and will not help in the option with inset. Shading is bad and very bad.

Let's expand the area for the bevel and get a dense mesh and the shading from very bad will become simply bad.

What else can be done?
We make 1 bevel for the inner edges and the second bevel for the outer edges separately and MANUALLY correct the overlaps. Finally, we get an acceptable result.

Total - three iterations, 2 manual selections, 2 bevels and 4 manual adjustments for corners. In this case, the mesh will be bad and it is better to delete 16 edges and make 8 new polysplits. And this is only for 1 hole. Too many nodes and manual operations! Parameterization is fictitious. If you have many holes, it is not viable. Compare with one operation in blender for any number of holes. It's ironic, but "destructive" blender in the case of bevel looks much more parametric than "parametric" Houdini.
Guys, bevel is an essential basic function, without which it is impossible to imagine modeling. But bevel in Houdini is an inconvenient and inefficient old node with bugs and shortcomings, which has no place in 2024. Please, make it relevant to the times, it's not 1990 outside!
Users, please, demand that developers stop building castles in the air and let them make basic tools normal.

@Cd = primuv(1, "Cd", 0, @curvepos);

Don't forget to delete the curves, they also remain and merge with the polygons and can greatly hinder you later.
It's easier to select the conjoint groups in the polyfill and delete everything except this group.

Also in the polyfill you can immediately choose to create a single polygon.
In fact, a regular boolean is used here.
You have 2 separate curves and one is nested inside the other. The polyfill fills each curve. And you just need to make a boolean and subtract the smaller polygon from the larger one. Which is probably what Hole does.

AslakKS
Or use the fuse node in match attribute mode and disable the `snap distance` & `output position`. That would only keep one of each value

Image Not Found

You are a genius! We completely forgot about this wonderful function in fuse!
But I will note, if the points are connected, then you need to disable "remove point from degenerate prim" otherwise the remaining points will disappear and you will not understand what happened.

So, our unloved bevel.
I've been writing to support about these bugs for a whole year and unfortunately I see complete ignoring from the developers.
If you agree with me that having such errors in the basic function in Houdini in 2024 is simply unacceptable from any point of view - like, comment, attract the attention of the developers.

1) A stupid error in the scale by attributes, making it useless. Here is a demo cube and you logically want to reduce the bevel on narrow faces using an attribute. Without an attribute, your bevel is perfectly set to the limit. You apply the scale by the pscale attribute and ... your bevel stops moving on one side. Why? Disabling collision immediately fixes the problem and gives an answer - Because the offset is multiplied by the pscale, and the collision calculation is not multiplied. Incredibly absurd! They use different distances! Therefore, the smaller your pscale is, the sooner your bevel hits an invisible wall, and the larger your pscale is, the stronger the overlap will be before the collision calculation "sees" the collision. A simple arithmetic error that turns your bevel into garbage. I remember this every time I need this function. It's sort of there, but there's no point in it.

2) Bevel accuracy on inclined edges. Here's a square extruded into a pyramid with strongly inclined edges. It's better seen on it. A completely symmetrical figure, right? We apply the bevel and see that there is no symmetry at all. A simple square! And if you rotate it, you can see that the calculation error is somehow related to the angle of the edge to the world axes, since with a slight rotation the bevels constantly change their sizes. Horribly inaccurate. It catches the eye when you need to bring the bevels close to each other. We remember that beauty is always symmetry.

Enivob
Data is associated with the context where you created it. I'll assume you added those values to the point context. To remove the additional data, just delete points.

I think the author meant an algorithm for removing duplicates and leaving only points with unique values. As far as I remember, there are no such ready-made functions for removing duplicates in Vex? Only through the for loop you need to make an algorithm, as it seems to me.

Oh, thanks, malexander! It's always good to get some clarification on where we're going.