[ Edited to add gcoap_opt_add_string() ]

I have an outline now for adaptation of gcoap for #8772. Overall, I don't see any issues. The existing gcoap API can remain, and I'll add a couple of functions for options. For implementation, I'll add a stack-based buffer for compiling options and an additional memcpy(). The overall gcoap approach remains -- a higher-level API to CoAP.

The gcoap functions for adding options will be like:

gcoap_opt_add_buf(pdu, optnum, buf_ptr, buf_len)
gcoap_opt_add_string(pdu, optnum, string_ptr, separator)
gcoap_opt_add_value(pdu, optnum, uint32)

The implementation appends option values to the packet buffer as they are provided by the user. The user is not required to add Options in order by option number. These values will be in the format of the raw data, like a query string. gcoap will use the new coap_optpos_t options[] array to store the position of these options in the buffer. gcoap will move the packet payload pointer as options are added, so it will be ready for the user when they decide to write the payload. You can see an example of this approach below.

   +-------+---------+---------+---------+----- ... --+
      hdr  |  path   | uint32  |  query  |    payload
           |         |         |         |
        opt_pos   opt_pos   opt_pos    payload*
        Uri-Path  Observe   Uri-Query

Finally, gcoap_finish() will sort the Options into order by option number. It will create a stack buffer, and use the nanocoap functions like coap_put_option() to write the contents in order to the stack buffer. Finally, gcoap will copy the stack buffer to the packet buffer and do the final memmove to reposition the payload, as it does currently.