fgillis
And, I have no idea where to start instancing in Solaris/Lops/Karma similar to the older, simpler way of just using "instancefile" or "instance" point attributes.
The instance/file attribute and instance object workflow is outmoded except for some third party renderers that don't understand packed prims such as Redshift. (Although Redshift probably supports packs now, it didn't at first.) Perhaps Redshift's dev adopted that workflow for instancing first since it was simple to implement in Houdini and now it stuck around as a standard workflow longer than it would have otherwise. Copy to points with packed prims or alembic prims is what I would consider the state of the art workflow--and solaris instancer node works roughly the same way. You can even skip the instancer node and import packed prims directly from sops--and they'll keep their instancing.
For building instancing natively in LOPs, start with the same point cloud in sops as for copytopoints: with the transform attributes, instance identifier (variant), and any other attributes to be copied. Use this point cloud as the Internal or External SOP target points source for the instancer. I wouldn't use "first input's points or primitives" that are on the usd stage for instancing as these will also be rendered along with the instances. Using prims might be useful for placing lights or something, but I can't think of a use for copying to a points prim (USD native particles).