The .ipynb format mixes source code with nondeterministic program output in the same file and regularly has backwards-incompatible format "upgrades". Those two make version control a nightmare. The files are also huge because they typically contain humongous base64-encoded PNGs.
The execution model also keeps invisible state in the running kernel, so fairly often if you restart the kernel and re-execute all cells, you'll get a traceback or, worse, subtly different results (and, alarmingly for something called a "notebook", your old results have been erased with no confirmation and no undo). This can happen for a variety of reasons, like deleting the definition of an object you are still using, or defining a new object in the last cell, using it in some subsequent cells, and then going back and changing some earlier cells to use it too.
If you get an .ipynb file from a coworker, you need to read it carefully before hitting "Execute all below" in case there's a cell saying something like "execute this cell to do an emergency shutdown of the production server", because that is a thing people do with entirely good intentions.
The problems described here notwithstanding, it's not exactly what I meant when I mentioned _fundamental_ flaws. I was referring to the decision to follow the paradigm where to share an MS Word or Excel document, the recipient will need to acquire and install a copy of Microsoft Office (or research acceptable third-party compatible viewer programs—an exercise even more fraught than installing Office proper).
Another commenter went on to write a lengthy comment (likening it to an IDE, however, which is an analogy that doesn't really work, and where the Excel comparison is really most apt): <https://news.ycombinator.com/item?id=45815212>
> We're literally asking users today 'to view this notebook install Jupyter/Marimo/whatever and open from there' when the Notebook is designed to create the publication […] In general the output i demonstrate above should be the minimum bar [for what a notebook is]
Any desktop preparation pipeline for ostensibly sharing research that doesn't leverage the ubiquity of the World Wide Wruntime needing no installation (either that, or able to output self-contained, source-carrying executables supporting decompilation that you're expected to run like a video game rather than open like a PDF—all of which is fraught with other obvious problems) is not really solving the research-sharing problem. Jupyter just repeats what has always plagued the Python world and was never solved despite the existence of e.g. Anaconda.