There is always a balance in what we do. If you're ever unsure about a decision like the posted question then within SysDev we should generally all try and move in one direction. We go with: KISS.  Keep it Simple and Stupid.

It's ok to program in a certain way, using design patterns to make sure maintenance is easier. But it has a nasty pitfall of 'over-preparing' for something that 'may happen' in the future. This can lead to complicated code for the small thing you're trying to add right now.

In this case I would say: better to add the retrieved columns behind the SNMP ones and deal with the problem of adding more SNMP columns later when the problem is actually something to tackle.

If you then encounter the problem then remember:

it is not possible to have; SNMP - Retrieved - SNMP

It is however possible to have: SNMP - Custom - SNMP  (if you don't use the basic getnext snmp retrieval) (OK: getnext+multipleget, MultipleGetNext, MultipleGetBulk)

So if you need to add more snmp behind retrieved, the correct flow is

1. Simply request and create a new Major Change range.  In a lot of cases, it's only about moving IDX's which will only impact specific external applications like through the webUI. Most elements & AS's use the PIDs of columns (except in the case of doing a full external gettable)
2. Without Major Change: Change retrieved into custom. Adjust the quickactions to take that into account. (no use of setcolumn)
3. Without Major Change: If adjusting the quickaction to set cell by cell is too impactful, the alternative way is then and only then consider moving the snmp to a new table, adjusting current table to be fully retrieved and doing the copy quickaction then.