Often times one will set up an nCloth constraint and then wish to edit the topogy of the input mesh, for example to increase the number of faces. The indices of the faces and vertices may be changed and so it may require reselecting the constraint components and doing "nConstraint: Replace Members", which can be tedious.

There are some ways to make the constraints more independant of the mesh topology, but they generally add some complexity.

The simplest is to constraint all components or all boundary components instead of a subset of points. If you created a constraint with an object or all its components selected it automatically makes the nComponent.elements = "ALL". Changing the resolution of the mesh will still have it constrain all the points(or faces or edges). If you want instead to constraint all border components you can set the nComponent.elements to "Borders". After changing the resolution it will still constrain all borders.

The "ALL or Border" selection on the nComponent can be further restricted by texturing the strength Map attribute. One can "paint properties by texture map" or use any 2d procedural texture. Where the map is black the constraint will have no effect. Note that "painting by VERTEX map" will not often work in this case, as the vertex mapping array may not map well to the changed topology. A UV texture does not have this problem, but it does require that you have well defined UVs on your surface.

Another way of restricting the connections is to set the constraint "Connection Method" to "Max Distance" as well as adjust "Connection Density". Note that this does not yet work with point to surface constraints ( it does work with point to face constraints, however )

The above methods attempt to define the constrained components implicitly throught relations (for example as border edges that are within a fixed distance of each other at the start frame) instead of explicit arrays of component indices.

Also when you create the constraint there is an option to use sets. This maintains the component indices on set nodes instead of as an array on the nComponent node. This setup adds a fair bit of complexity, but for some setups can potentially allows changes to topology without needing to reassign the constraint links. But in practice I've found that there are few cases where it is really useful, and the correct translation of the sets is not consistently handled by the different construction histories. For it to work at all the new construction history has to occur downstream of the set connection to the input mesh, but before the nCloth node. As the set definition is passed through the construction history, for example a smooth node, the set is modifed to preserve as much as it can. The constraint then gets this modified set of components. However I would stay away from using sets with constraints unless you are an advanced user that understands them well.