Implementer feedback is solicited on Hub Generated `syncerror` Events particularly on the following topics:• after the first time a Hub has distributed a syncerror indicating that an application is not responsive, should the nonresponsive application be automatically unsubscribed (removed from the Hub's list of applications subscribed to the topic)? This would avoid syncerror events being sent after subsequent operations; however, it may conflict with the approach of syncerror events generated by the Hub only being distributed to subscribers of the event which triggered the syncerror event to be generated.• should syncerror events generated by the Hub be distributed only to subscribers of the event which triggered the syncerror event to be generated? However, this could conflict automatically unsubscribe a non-responsive application after the initial syncerror is generated and distributed.

No 

* should all FHIRcast requests trigger syncerror events to be generated by the Hub for an unresponsive application or only when a context change is requested ([FHIR Resource]-open or [FHIR Resource]-close)?

Yes, or a mechanism to limit the scope of sync-error messages.

* should all FHIRcast requests trigger syncerror events to be generated by the Hub for an unresponsive application or only when a context change is requested ([FHIR Resource]-open or [FHIR Resource]-close)?

Only context changes. If the previous comment is accepted, it does not really matter.