[BUG] Strange behavior with NIP-33 parameterized replacable events and NIP-40 (expiration tag)

[dskvr]

Describe the bug
There appears to be a ghosting affect when mixing NIP-40 and NIP-33. I spent a few hours trying to track down what was going on, and am fairly certain I have eliminated human error on my side.

To Reproduce

1. Pick a kind in the parameterized replaceable event range
2. Publish an event.
3. Subscribe with filters for that kind. Observe expected behaviors
4. Add an expiration tag with a UNIX timestamp sometime in the future.
5. Publish the event.
6. Observe incorrect behaviors (event is not stored)
7. Remove the expiration tag.
8. Publish the event again.
9. When subscribing, the event will not be returned, suggesting it was not stored.
10. Subscribing with filters for that kind before the event is published will show that the event is returned once by the subscription but if you resubscribe that same event will not be returned; similar to the behavior of an ephemeral kind.

Expected behavior
expiration tag on an event kind has absolutely no effect on future events of that kind.

Screenshots

System (please complete the following information):

• nostream@1.22.6 (issue began in a previous release)
• ubuntu@22.04

Logs
There was nothing in logs to suggest anything was wrong.

Additional context

• Was experimenting and updating an implementation on a private relay to include NIP-40 expirations.
• Before adding the expiration field, the issue did not exist and events were publishing without issue for ~2.5 months
• Nothing changed in event publishing logic (other than removing a tag and adding the expiration tag) nor in the client logic.
• I isolated the test case and was able to reproduce the behavior.

[cameri]

@dskvr my man I could not reproduce this. If you ever encounter this issue again let me know and I'll re-open :/