La explicación que da Musk, no creo que sea cierta, suena como un poco más  a casual (una excusa barata preferible a...), cuando la realidad, me parece que se acerca más a la torpeza...

Mi primera impresión al ver el vídeo, es que fue un sobrecalentamiento de los motores a causa de los gases expandidos en la propulsión, que al momento de posarse, la zona ocupada por la propia nave, estaba sobrecalentada...

...vamos es casi la misma situación del mítico juego 'Lunar Lander', solo que en el juego, (cuando fallabas en el aterrizaje) la destrucción era debido a un choque por la velocidad de impacto al tratar de aterrizar... salvando la distancia entre la 'velocidad de impacto' y la 'velocidad de disipación del calor bajo el propio cohete', para mi es un fiel reflejo.

En las últimas decenas de metros antes de tocar suelo, se debería apartar las toberas de escape graduando el ángulo hacia afuera a medida que va descendiendo.

En efecto... las dll tipo API, es como bien señala Tincopasan y tú mismo...

Me faltó señalar que '...la otra situación que puede darse con las dll...' que omití precisamente porque ya había respuesta dada, aunque al escribir el mensaje me pareció que era como mucho deducible, ahora al releerme no me parece tan obvio, así que gracias por añadir la diferenciación para impedir que induzca a cierta ambigüedad.

Cuando editas una dll que usa un programa y que está registrada (en el registor del sistema), cuando el ejecutable tratade cargar dicho ejecutable se localiza mediante su CLSID, como quiera que dicho valor habrá cambiado con tu modificación 'entenderá' que se trata de una version distinta.

Prueba primero a localizar en el registro la dll y haz copia de la rama/s que la contengan (junto con la dll original), luego registra la dll modificada, se creará un CLSID distinto del previo...
Si el programa instancia la dll por su servidor.nombre (late binding), seguirá teniendo acceso a ella, pero si el programa mantiene referencia a su CLSID (early binding), no funcionará, en cuyo caso tendrías que cambiar (también) en el programa... el CLSID, que referencia la dll (en todas las partes que apareciere), por el nuevo que arroja tras el registro después de editarla.

Otra cosa es que tras las modificaciones, tengas que usarlas en tus programas, simplemente registras la dll, y tu programa la instancia, no importa el CLSID que tenga ahora, porque es el que tu programa tomará... en este caso conviene además cambiar nombres, para evitar que una versión modificada (para uso personal y propio), no malogre el acceso y uso a la misma dll (la original sin modificar), que pueda necesitar uno o más programas del sistema.

Lo que quieren es que pienses, que sepas cómo sucede, no simplemente que hagas que suceda...

Dicho de otro modo: Quieren que uses bucles y que cambies elementos de un array a otro o dentro del mismo array usando variables temporales e índices entre elementos.
No quieren que utilices métodos de objetos que te faclitan el trabajo... eso para cuando seas profesional ahora toca aprender como hacerlo 'manualmente'.

Tienes que sopesar cual tiene menor coste, lo que depende de:
 --- El tamaño del fichero.
 --- En qué punto del mismo se localice dicha línea.
En resumen el tamaño del ficheor antes y después de dicha línea.
Además, si no es la única línea a borrar, conviene retrasar la operación, almacenar los datos referentes a su localización y tamaño en alguna estructura de datos y cuando se tenga la info de todas las que se deseen 'borrar' proceder co el borrado de todas en una misma y única operación... porque borrar una sola línea de cada vez tiene un elevado coste.

Hay dos formas de hacer lo que quieres:
1 - Si la línea ocupa pongamos 40 bytes, bajas todos los que estén por encima de la línea exactamente 40 bytes, para cubrir el hueco que ocupaba dicha línea... y sobrescribes los 40 bytes finales del fichero a 'cero' (por ejemplo). El tamaño del fichero sigue siendo el mismo, luego operaciones de tipo 'append' escribirían al final de dicho fichero, sin considerar ese espacio de 40 bytes del final...

2 - El otro modo soluciona el problema antedicho, pero el coste es algo mayor, tanto mayor cuanto más grande sea el fichero y más al final este dicha 'linea 'borrada'..
Creas un fichero nuevo, copias todo el contenido hasta el comienzo de la línea a borrar, y luego todo el contenido tras la linea a borrar, en resumen copias todo excluyendo dicha línea.
...luego al terminar cierras y borras el fichero que contiene la línea que querías borrar., y al nuevo lo renombras con  el nombre que tenía el ahora borrado.
Por supuesto si has leído un fichero enteramente en un array de líneas, la operatoria se puede simplificar, cerrando y eliminando el fichero actual y creando uno nuevo del mismo nombre que el eliminado, ahora escribe todo el contenido que mantienes  en tu array, omitiendo justamente las líneas que se quieran 'borrar'.

Los ficheros ocupan un espacio contínuo en el disco, luego el coste asociado con borrados en medio de un fichero tienen un elevado coste.
Si el fichero mantiene algún tipo de estructura, registros, lo que se suele hacer es simplemente marcar un registro como 'vacío', el contenido del mismo no precisa ser tocado, salvo que contenga algo que por seguridad no pueda dejarse así, en cuyo caso se sobrescribe con contenido aleatorio...

Cuando deba añadirse nuevos registro, siempre lo harán en registros borrados con preferencia a añadirlos al final del fichero.

Si se acumulan demasiados registros sin borrar (cuand esté muy fragmentado), según el diseño... puede interesar 'defragmentar', haciendo exactamente lo que se señala en el apartado '2', copiando el contenido total del fichero a otro, excluyendo los registros vacios...

Ni idea, no uso Tiktok...

Pero mira en la configuración del programa a ver si permite señalar una carpeta específica.
Si no es así, es algo por diseño, entonces lo que tendrías que hacer es solicitar a los desarrolladores que cuando menos opcionalmente se pueda elegir una carpeta, si no quieren crear una específica 'tiktok'... que t lean y acepten es ya otro cantar.

Los planetas y las estrellas están formados en capas como las cebollas...
Cuando se crea haber encontrado el núcleo... tras 'pelar' esa capa encontraran que debajo hay otra, más pequeña... dudo mucho que la referida (en el artículo) sea exclusivamente de hierro (y/o níquel), y dudo mucho que sea la 'última capa', más pequeña y profunda habrá otra capa (un núcleo para el núcleo) compuesta cuando menos de materiales (ligeramente si no muy) distintos.

Es un problema del absolutismo científico... "solo existe lo que podemos demostrar"... y cierran el libro, en vez de decir: "solo podemos demostrar ésto, pero no sabemos si ésto es el límite".

...así que a medida que mejore la tecnología se encuentran más cosas, toca cambiar los libros y llamar idiotas a los anteriores científicos...

ya... justo cuando te lo compres, y luego te enteres que ya no es compatible con el nuevo S.O. que acaban de sacar... Si con un procesador que te costaba 50-80 euros ya te daba un disgusto, con uno 100 veces más caro, el disgusto sería de espanto 

No se sí reir o llorar.

Me da pena que se fastidie, habrá costado mucho dinero y esfuerzo y espero que si encuentran la causa, como parte de la solución no tomen medidas consistentes en 'despedir al culpable'.

Lo que me da risa en cambio es eso de 'colonizar Marte'... Si construir un cohete que funcione perfectamente (todas las veces), es complicado, no saben la que les espera. Un planeta deshabitado (de humanos al menos), cuya atomósfera, es irrespirable, temperatura extrema, sin agua, ni comida, ni respuestos... y que haya tanta gente desesperada por ir... casi diría que quieren pasar a la Historia como los primeros muertos en Marte (si antes consiguen llegar).

Marte no estará 'al alcance', hasta que no tengamos tecnología mucho más capacitada, digamos que cuando seamos capaces de llegar a Marte en un viaje de unas pocas semanas (1-6), podremos asumir que la tecnología haya mejorado lo suficiente en todas las áreas como para que Marte sea asequible.
Mientras, apoyo todo el esfuerzo que ponen porque a fin de cuentas contribuye a mejorar e innovar tecnología. Un buen reto pone a prueba los límites, que es lo necesario para seguir mejorando...

...algo muy esperado, ya veremos a ver como anda, y si se le pone la zancadilla...