So, since RBF applies only to pending transactions in the mempool awaiting incorporation into a block, there is a window of opportunity in which the pending tx is incorporated into a block at the same time that the spender is constructing and publishing a replacement for that pending tx. 

The replacement transaction would be rejected by the peer network as a double spend because it conflicts with the now confirmed original tx, and the spender will have to go back and create a new stand-alone transaction to accomplish what they hoped to do with an RBF replacement.

So an implementation that wishes to take advantage of RBF will still need to have a "plan B" implementation path to handle the corner case of a replacement tx being rejected as a double spend.

Is this correct?  

I'm just trying to get my head around the implementation cost vs benefit of RBF in the context of my applications.

Thanks,

-Danny