Element.Solids nodes convert Revit elements to Dynamo geometry (surfaces and solids respectively). During these operations, the boundary edges of each face of the Revit element (Revit solid/surface) are extracted and converted into Dynamo
Polycurve(s). Next the Revit face is converted into an untrimmed Dynamo surface and finally the polycurves are used to trim the untrimmed surface to produce the exact trimmed Dynamo surface.
Dynamo uses a geometric kernel that like most kernels is sensitive to floating point calculations due to which reason geometric operations may not work reliably with floating point numbers outside particular ranges. You can read about this issue in detail and the solutions we provide to work around it in Dynamo in this post: http://dynamobim.org/think-big-geometry-with-lots-of-zeros/.
So in your case if you are using a model of a particular size with a geometry working range that is very large, the numbers used in the model (absolute size of the model) will be scaled down as you use a higher range. This would not pose a problem if the model is too large to begin with but if it is not too large, the numbers will turn out to be quite small after scaling them down and when these small values are used in the construction of the polycurves, some of the curves may turn out too small and therefore self-intersect or appear to branch (Y-shape). Since our polycurve algorithms do not support branched polycurves, we discard them. This in a nutshell explains why you find the nodes work with a smaller working range and fail with a higher one. I hope this answers your question. Unfortunately the geometry working range needs to be set on a case-to-case basis and depends on the size of the model you’re working with in terms of the absolute numeric dimensions being used. Therefore your graph may work with some models but not with all, in which case you’ll have to play around with the working range as is suggested by @Tom_James.
Btw, the error message is a typo and therefore very confusing. It should actually be worded the exact opposite, namely, “Polycurves may be branching” instead of “Polycurves may not be branching.” We’ll fix this.