yep server side behaviour is as intended, it's the client consumer handling that seems off to me. Correct me if I'm wrong (I don't know the ins and outs of the nats/jetstream protocol yet) but here's what I think is happening:

On a reconnect we loop through all subscriptions (sync ones held on connection directly, and async ones held by dispatchers) and generate resubscribe messages:

1. for non jetstream subscriptions this just works because they need no jetstream consumer creation
2. for durable jetstream subscriptions it works because the consumer is ... well durable
3. for ephemeral jetstream subscriptions it fails because we only subscribe to the inbox subject but do not recreate the consumer. Presumably this generates heartbeat alerts because it's the consumer creation that causes the server to emit heartbeats for that consumer/subscriptions.

Edit: So without having fully verified this I think the issue might not even be specific to KV watcher but rather to ephemeral jetstream subscriptions because during the reconnect the possibility of a server restart (i.e. ephemeral consumers are gone) is not handled.

Except for ordered consumer, which specifically tracks which stream sequence was received last, ephemerals will not resume, because they don't know where to start. The best thing is to be aware of the the event listener. You might need to track the ephemeral state yourself, to start a new ephemeral where you left off. An ordered consumer (see subscribe options) is a good option if you don't need to ack the messages.
Part of the question is where to draw the line on doing the work for the developer in the client.

Yeah that's a good point, but in that case I think more options need to be available in the creation of a key value watch. The subscriptions options are hard coded and not parameterizable.

Edit: also the KV watch is an ordered consumer iirc. So it would be applicable?