Sobre la 1ª pregunta: Cuándo guardas un dato, eso es un nombre, una dirección, etc. éstos no tienen implícitos cambios de línea Es de buena práctica separar los datos de su presentación: el dato es la cadena, la presentación dicta si debe haber un salto de línea o no. Por consiguiente sí, es bueno quitar el salto de línea.

Sobre la 2ª pregunta: fgets copia los N primeros caracteres teniendo en cuenta siempre que el último carácter de la cadena destino será '\0' así que en verdad se copian N-1 caracteres; de esta forma fgets se asegura que en el destino hay una cadena con su final. Los caracteres que no fueron copiados se quedan en el búffer del teclado.

Sí, z cambia de dirección, es una cadena diferente. Lo puedes ver usando el argumento % p de printf.

Mucha:
El array contenido de un array, si es una variable automática, se guarda en la pila, en cambio en un puntero es este mismo el que se guarda en la pila y su contenido en el montón (heap) si se da su valor con malloc, calloc, realloc, etc. O en la zona de memoria de datos de sólo lectura si se le da el valor directamente con una cadena.
Si a un array se lo inicializa con una cadena, C crea código por debajo para copiar la cadena al array, en cambio el puntero guarda la cadena en memoria de solo lectura y apunta a ella.
A un array se le puede modificar el contenido, pero no sus características (zona a la que apunta su nombre,  el tamaño); al array se le puede cambiar la dirección a la que apunta, peri no su contenido si este es una cadena literal.
Con esto puedes ver que un array y un puntero,  aunque se vean muy parecidos, son dos cosas muy diferentes y debes elegir cual usar según el tratamiento que vayas a hacer de los datos.
Una cosa curiosa es que si dos arrays distintos los inicializas en el código con la misma cadena (sendas cadenas iguales), el compilador sólo guardará una cadena en memoria y los dos punteros apuntarán a ella. En cámbio,  si haces lo mismo pero con arrays cada uno de ellos guardará su propia copia de la cadena, así gastará el doble de espacio.

No se ve el código.

Bin0010, le pasas a setModelo una cadena cuando el método espera un entero.

Antes del inicio del main te sobra el último };

¿Qué error te dice el compilador que hay?

Por cierto, tienes pérdida de memoria en la linea

*files = sTemp;

*files apunta a una zona a la que has adquirido memoria con calloc pero no la liberas antes de la nueva asignación.

Para solucionar eso, y saltarte un paso en ello, haz realloc sobre *files mismo; realloc se encargará de liberar la memoria y ocupar otra para *files, que para eso es su trabajo.

La función de Kaxperday solo funcionaría para tipos de datos no reales, ya que estos tienen una representación interna diferente.

Elginah, el error que tienes marcado en rojo es que comparas el valor de algo que se guarda en el array con la dirección de inicio de ese array.
El nombre de un array devuelve siempre su dirección de inicio, para acceder a un valor que contenga, aunque sea la primera posición debes dereferenciarlo, ya sea con notación de puntero, ya sea con subíndices (notación de array).

La primera y la tercera me gustan, la tercera me gusta más. La 2 no la haría.

Tambien puedes encadenar ifs:

bool retValue = false;
if ( func1 ())
if ( func2 ())
if ( func3 ())
    retValue = true;
 
return retValue;
 

Queda bonito, visible a simple vista y quitas letras de enmedio.

El que haya un solo return por función es una de las corrientes de estilo de programación y tiene muchos seguidores, yo me incluyo, aunque no la llevo a rajatabla.
Es como otras como no salir de los bucles con break, no usar goto para la lógica, etc.
Yo digo: todos estos estilos tienen su espacio y su momento. Hay que usar el que, en cada momento,  deje más claro el código a la hora de revisarlo.