So I unfortunately just noticed that any subclassing of this resorts in the instances within an actor to be unselectable in the viewport of an actor. I’m using 5.5.4
The mouse will show the icon but they are completely unclickable.
Using a regular ISM does not show this behavior. It is easily reproduced. Create a BP of a ISM, drag it into an actor viewport, set a mesh and create any number of instances.
Enjoy the heartache. 
Hey there, I just investigated this.
The handling of mouse clicks in the viewport for InstancedStaticMeshComponents is handled by FInstancedStaticMeshSCSEditorCustomization, but this handler is registered explicitly for that component class. This happens in FBlueprintEditorModule::StartupModule() with a private class, so you’re out of luck:
// Register internal SCS editor customizations
RegisterSCSEditorCustomization("InstancedStaticMeshComponent", FSCSEditorCustomizationBuilder::CreateStatic(&FInstancedStaticMeshSCSEditorCustomization::MakeInstance));
RegisterSCSEditorCustomization("HierarchicalInstancedStaticMeshComponent", FSCSEditorCustomizationBuilder::CreateStatic(&FInstancedStaticMeshSCSEditorCustomization::MakeInstance));
I’ve logged this as a UE bug: UE-348569. Keep an eye on that for fixes.
If you’re C++ savvy, you can consider duplicating FInstancedStaticMeshSCSEditorCustomization code to your game project and registering that as an SCS Editor customization. Otherwise, you’ll need to work around the limitation.
Awesome thanks. My project is c++ maybe I’ll take a stab at that. I imagine we could re-direct selection and/or manipulate the selection to specific instance indexes ?
I’m using a helper struct to build walls and keeping track of sections based on index, ISMs seemed logical just mesh per material.
No problem, happy to log that bug for you since it’s a confusing one to run into.
You can have a look at having that actor class implement ISMInstanceManager:
* An interface for actors that manage static mesh instances.
* This exists so that actors that directly manage instances can inject custom logic around the manipulation of the underlying ISM component.
There are some examples of that in engine code. I don’t have hands-on experiencne with that myself so I’m not sure how user friendly that is, but it sounds like it’s the intended approach for game code to manage instances in special ways.
Definitely will take a look.
I was able to make a BlueprintEditorModule and register my subclass for the customization. We can select them now 
It looks like there may be some logic to play with for HandleViewportClick. Again thank you very much.
Strictly for bookkeeping but I was also able to re-direct the click to a different ActorComponent. My walls are generated from WallSegments.
override HandleViewportClick
if (BlueprintEditorPtr.IsValid())
{
// Note: This will find and select any node associated with the component instance that's attached to the proxy (including visualizers)
//BlueprintEditorPtr.Pin()->FindAndSelectSubobjectEditorTreeNode(InstancedStaticMeshInstanceProxy->Component, bIsCtrlKeyDown);
bool bSegmentSelected = false;
UWall* Wall = Cast<UWall>(InstancedStaticMeshInstanceProxy->Component);
if (Wall) {
const UWallSegment* WallSegment = Wall->GetWallSegment(InstancedStaticMeshInstanceProxy->InstanceIndex);
if (WallSegment) {
const UActorComponent* ActorComponent = Cast<UActorComponent>(WallSegment);
if (ActorComponent) {
bSegmentSelected = true;
BlueprintEditorPtr.Pin()->FindAndSelectSubobjectEditorTreeNode(ActorComponent, bIsCtrlKeyDown);
}
}
}
if (!bSegmentSelected) {
BlueprintEditorPtr.Pin()->FindAndSelectSubobjectEditorTreeNode(InstancedStaticMeshInstanceProxy->Component, bIsCtrlKeyDown);
}
}