Estas haciendo deducciones inventándote cosas. Eso de tiempo de edicion, evaluación mientras escribes código, tiempo de build...
Solo tienes comprobación en tiempo de ejecución. Y comprobación en tiempon de compilación.

Cuando una condición se comprueba en tiempo de compilación quiere decir que mirará el valor que le has puesto. Imagínate este hipotético código:
int bytes = 4;
cout << "Introduce los bytes a comprobar";
cin >> bytes;
static_assert(sizeof(int) == bytes, "Su sistema no es de 64bits");

Al ejecutarse ese código en tiempo de compilación, quiere decir que static_asert comprobará 4 en la condición. Da igual que el usuario cambie el valor de la variable durante la ejecución del programa porque la sentencia ya se comprobó cuando se compiló el código. Eso es "En tiempo de compilación".

Si se comprobase en tiempo de ejecucción, la expresión se evaluaría después de que el usuario pusiese el valor de la variable.

Es así de sencillo. No tiene más complicación.


static_asert se suele usar para no compilar ciertos trozos del programa si ocurre un error.
Por ejemplo yo hago un código e incluyo unas librerías del 2019 de 1gb de tamaño y uso todas las nuevas funciones.
Tu descargas mi código y lo compilas con tus librerías sin actualizar del 2018.
El compilador va a tardar un buen rato en buscar en la librería las funciones para 10 o 20 minutos después darse cuenta de que no existen esas fuciones en la librería. Asique perderías 20 minutos para nada y no sabrías cual es el problema.

Si yo fuí previsor, podría utilizar un static_asert para comprobar la versión de la librería y ahorrarte 29 minutos de tiempo para nada. Ejemplo:
#include "libreria.h"
static_assert(libreria::Version < 2019,  "No estás usando la libreria2019. El programa no compilara. Actualiza en www.libreria.inv/last-version para utilizar el programa);

También puedes usarlo para que te avise al compilar si has hecho algo mal.
Para forzar números aleatorios y todo lo que se te ocurra.

Podría forzar a compilar con un número aleatorio, y como una vez compilado el programa no se volverá a usar un número aleatorio, no dará problemas ese ejecutable. Y podras hacer por ejemplo varios ejecutables con números de serie aleatorios.

int miVariable= estaFuncionRetornaUnIntAleatorioEntre0y100();

static_assert(miVariable>50, "El numero no es mayor que 50, intenta compilar otra vez");

static_assert como dices, es una comprobación "en tiempo de compilación". Si el compilador detecta una contradicción al evaluar el static_assert suspenderá la compilación (y emitirá el mensaje de error optativo).

Pero... ¿por qué el Visual Studio (y otros IDEs) muestran una marca de error antes de compilar?

Para el caso del editor de código del Visual Studio la herramienta se llama IntelliSense https://docs.microsoft.com/en-us/visualstudio/ide/using-intellisense?view=vs-2019, que entre otras cosas, es la que señala errores con una linea roja y sinuosa (error squiggle), como cuando escribes en un editor de texto con faltas de hortografía.

Este tipo de herramientas (error squiggle, code-completion, symbol searching, go to definition, ...) son muy difíciles de implementar en C++, y durante años han sido una pesadilla para muchos fabricantes de IDEs (y lo son aún), así que no hay que asustarse si alguna vez falla. Imagina un proyecto que demora en compilar 20 minutos, pero el error-squiggle se muestra instantáneamente con cada tecla pulsada.

entiendo, entonces es del IDE, no del compilador...
podria salvar varios minutos de compilacion...

llego un momento en que me pregunte : para que rayos tengo que darle un segundo argumento con el error si ya de antemano me lo esta señalando...

gracias por las respuestas.