I'm not sure what you're trying to achieve. I'm actually confused on your text.
You started describing the ACK process, which most messaging systems implement.
Then you started describing messages sent from a topic to a queue?
Can you clarify what you mean with a simple statement please?
Hm..I'm not sure why I'm having such trouble describing what something that is basically quite simple
First, this is my understanding:
Durable topics record all messages. This is because 'topic' is a broadcast mechanism and the server doesn't know when any client may connect and ask for the whole history of messages.
Durable queues only record messages which have not been acked by the client. Since queues are 1-to-1 mechanism, once the client acks a message, the server assumes it no longer needs to keep a copy itself.
If this understanding is correct, then in a durable queue scenario, if a client acks a message, but later loses it, there is no way to get it from the server again. I'm trying to figure out if it is possible to make durable queue remember all its messages forever (or until cleanup is run). This way, even if the client loses the message it has already acknowledged, it can still get the whole history again. Or is it better to simply use a topic for this scenario rather than a queue?
A message stays on a queue (that is durable or not) as long as you didn't Acknowledge.
You can't use a message system as a database. you will build up messages on memory.
You could use a Browser, but you will end up on the case described above.
You should use the right tool for the right thing. Have a Consumer listening for the data and add it to the database. Recover it from there when you need.
BTW: using a message system as a database is an anti-pattern for any messaging system.