Split this protocol into 4 roles, then design accordingly, such that the maker declares two things.
What is on offer (something fungible + popular, but double-spendable eg. USD, or something non-fungible + unpopular, eg. real-estate).
What security guarantees are offered (by the maker) and what is required (by the taker) to execute the trade.
4 Roles
BTC-sender-maker
BTC-sender-taker
BTC-getter-maker
BTC-getter-taker
Expect mature clients to abstract this complexity down to 2 (maker/taker).
Then, drive the protocol sequence and optional features based on declarative options and terms set by the maker, using logical defaults if not over-ridden by the maker.
Takers simply let makers compete, and don't have much wiggle room to negotiate. Makers can optionally list choices or flexibility in their terms.
4 Roles