The version change did not solve this issue, but I have found a workaround.
Setting DisableSubscriptions = true on ModbusTCPCom1 caused all of the labels to exhibit this behaviour, so it seemed to be a result of subscriptions failing to be established.
However, Subscription.SuccessfullySubscribed = true for the malfunctioning labels.
I suspect that the root cause is the CLICK Koyo PLC, as closing and reopening the form (as opposed to show and hide as I was doing) would randomize which labels failed (usually none), the same as a full restart had previously.
I ran a timer on the form, and on intervals ran the following subroutine, where L() is a list of the BasicLabels.
Private Sub Check_Subscription() 'procs ever 200ms. About 6s to do the whole page
Dim address, format, suffix, temp As String
address = L(Check_Index).PLCAddressValue
format = L(Check_Index).NumericFormat
suffix = L(Check_Index).ValueSuffix
Try
temp = ModbusTCPCom1.Read(address, 1)(0)
temp = CType(temp, Double).ToString(format) + suffix
If L(Check_Index).Text <> temp Then 'If the value does not match the PLC value, re-subscribe
Invoke(Sub() L(Check_Index).PLCAddressValue = "400000")
Invoke(Sub() L(Check_Index).PLCAddressValue = address)
End If
Catch ex As Exception
End Try
Check_Index += 1
If Check_Index >= L.Count Then
Check_Index = 0
End If
End Sub
Changing the address of the label forces the BasicLabel's SubscribeToComDriver method to run, and doing so established a functional subscription.
It certainly is a bodge, but I'll leave that for posterity.