Cierto, aunque es necesario contar tanto con el selector de segmento como con el desplazamiento (offset) para para obtener una direccion segmentada con la que poder trabajar.

---

The segment address is always added to a 16-bit offset in the instruction to yield a linear address, which is the same as physical address in this mode. For instance, the segmented address 06EFh:1234h (here the suffix "h" means hexadecimal) has a segment selector of 06EFh, representing a segment address of 06EF0h, to which the offset is added, yielding the linear address 06EF0h + 1234h = 08124h.

Because of the way the segment address and offset are added, a single linear address can be mapped to up to 212 = 4096 distinct segment:offset pairs. For example, the linear address 08124h can have the segmented addresses 06EFh:1234h, 0812h:0004h, 0000h:8124h, etc.

https://en.wikipedia.org/wiki/X86_memory_segmentation

---

Volviendo al ejemplo original los segmentos declarados por TASM arrancan en (entre otras direcciones segmentadas):
ref 0710h:0000h
seg 0710h:0002h
seg2 0710h:0004h
cseg 0710h:0006h

Poner el selector de segmento en AX no es suficiente para acceder a los datos (AX no sirve como indice tampoco), ni saber donde arranca el segmento declarado en TASM.

Para poder acceder a los datos con los segmentos declarados en mi ejemplo:

entry:
mov bx, offset seg2
mov al, byte ptr [bx] ;esto no lee de 0:[bx] o [bx]:0, lee de ds:[bx] es decir ds:[0x8]
mov al, byte ptr cs:[bx] ;cs:[bx] es decir cs:[0x8] es 0x66
mov al, byte ptr cs:[2] ;es 0x3
 
mov bx, seg1
mov ds, bx ;ponemos en dx el selector de segmento
mov bx, offset seg1 ;ponemos en bx el desplazamiento
mov al, byte ptr [bx + 1] ;ds:[0x5] es 0x5
mov al, byte ptr [bx + 2] ;ds:[0x6] es 0x7

Si le damos nombre a nuestros datos como por ejemplo cambiando uno por despues podemos acceder a los mismos:

var db 7
...
entry:
mov bx, seg1
mov ds, bx
mov bx, offset var
mov al, byte ptr [bx] ;ds:[0x6] es 0x7

¿Que es un segmento sin su contenido? ¿Un rango de memoria? Separar un segmento de sus datos no tiene sentido, un segmento es un bloque de memoria, un conjunto de bytes alineado a un parrafo y esos bytes que son sus datos tienen valores. Sin ir mas lejos al declarar un segmento en TASM nos permite darle valor a su contenido.

"The segment alignment attribute tells the linker to ensure that a segment begins on a
specified boundary. This is important because data can be loaded faster on the 80x86
processors if it's properly aligned."

De la misma manera equiparar los segmentos de memoria y los segmentos declarados por TASM me parece errado como concepto y por lo explicado en este mismo hilo es imposible que sean exactamente lo mismo. Si seg2 es 0x910 y antes esta seg1 que es 0x910 quiere decir que seg2 no inicia en la misma posicion, por pura logica; es cierto que el segmento de memoria 0x910 siempre inicia en la misma direccion pero si podemos tener 3 segmentos declarados por TASM que inician en un mismo selector de segmento no podemos seguir diciendo que son lo mismo que los segmentos de memoria.

Hacer referencia a seg2 en el codigo es solo una parte - inconclusa - del trabajo necesario para acceder a los datos que el segmento declarado por TASM contiene, se necesita tambien un desplazamiento, el cual tambien se puede conseguir haciendo referencia al mismo seg2 con offset.

No se desperdicia nada, si inicia el segmento TASM con un offset de 2 bytes es que hay otro segmento TASM anteriormente ocupando 1 o 2 bytes (lo cual lo hace intrinsicamente diferente a un segmento de memoria que solo puede iniciar alineado a un parrafo). No es como lo planteas, offset de seg2 y offset de var1 son lo mismo, no hay nada que ocupe otros 2 bytes entre medias, el primer elemento de ese segmento no inicia en otro lugar que no sea el principio del mismo. Es cierto que offset es con respecto al segmento de memoria, es la unica forma de que funcione.

Si seg2 iniciara en 0910:000 siempre entonces offset daria siempre 0 para un segmento declarado por TASM y no es el caso, devuelve el desplazamiento necesario para poder hacer estos segmentos de TASM funcionales.

SEGMENT seg1 WORD
var db 7
var2 db 8
ENDS seg1
 
SEGMENT seg2 WORD
var1 DW 666h
ENDS seg2
 
SEGMENT cseg WORD
entry:
mov ax, seg1
mov ax, seg2
mov ax, offset seg1 ;0x0
mov ax, offset seg2 ;0x2
mov ax, offset var1 ;0x2

"The segment alignment attribute tells the linker to ensure that a segment begins on a specified boundary."

En este punto el manual es explicito (y tambien habla de la generacion de segmentos, los segmentos de memoria son pre-existentes al programa), el alineamiento le dice al enlazador que se asegure que un segmento comienza en un limite especifico, este puede ser en bytes: 1, 2, 4, 16, 256 y 4096.

En la practica podemos ver como eso sucede con los ejemplos ya publicados, y no estamos hablando de segmentos superpuestos, estos no inician en la misma direccion de memoria segmentada (de hacerlo hablariamos siempre del mismo segmento de memoria, parrafo X, direccion de memoria lineal X con igual o diferente tamaño, el cual el procesador desconoce), solo puede haber segmentos superpuestos cuando involucramos un selector de segmento + un desplazamiento - el ejemplo seria 0710h:0006h y 0709h:0076h ambas direcciones segmentadas apuntan al mismo lugar con dos segmentos diferentes - de otra manera tratamos exclusivamente con valores consecutivos de 0 a 0xFFFF. Aca hablamos de varios segmentos de TASM contenidos en un solo segmento de memoria por la forma de declararlos.

No se puede acceder de ninguna manera a 256 o 4096 bytes atomicamente (en modo real creo que a 16 tampoco, sinceramente esto me esta haciendo releer material precambrico), el alineamiento - que por defecto es 16 en TASM - no tiene que ver con eso.

El procesador no sabe nada de estos segmentos declarados en TASM, MS-DOS despues de cargar el ejecutable solo sabe que tiene que hacer relocalizaciones y gracias.

SEGMENT cseg 'lalala' << le dice a TASM genera un segmento de codigo (cseg) llamado lalala, esto (el nombre) no se ve reflejado en el binario, en el manual hay una muy breve explicacion.

Yo ya lo habia olvidado por completo, por suerte, pero al menos ahora tengo en la mente mas razones para agradecer estar trabajando con un modelo de memoria plano

¿Cual seria el riesgo exactamente? ¿Tener que lidiar con codigo de los años 80s/90s? Las probabilidades de que tenga la necesidad (el foro no cuenta, hablo profesionalmente) de depurar (debug.com/.exe desaparecio de mi SO hace rato largo cuando aparecieron a su vez los procesadores de 64 bits) y/o programar en ensamblador x86 de 16 bits son infimas por no decir nulas y ya lo eran incluso la decada pasada.