Recommend as simple as possible for the text, and start with pencil & paper for the diagrams. Then move no-longer-draft text into latex (for maths and formatting) and something simplish (maybe inkscape) for the diagrams.
You DON'T want to spend writing time doing any formatting and playing with computers ... that's an easy was to burn lots of time. Get the ideas (words & pics) clear and complete, then the formatting is quick.
And whatever you use, it should do everything with styles, not manually selecting bold-for-this and sans-for-that - that's just a waste of time (so avoid MS).
I agree with the advice for authors not to spend time on formatting—leave that to the editor, book designer, and compositor—but that’s not necessarily a reason to avoid Microsoft Word, which despite its flaws, has extensive facilities for character and paragraph styles, including a Limit formatting to a selection of styles option that prevents direct formatting.
Indeed, many publishers are set up to accept manuscripts in Word documents as the input to their editorial and production workflows, which generally use other software for the actual typesetting and e-book production.
My french teacher back in high school was also an emerging novelist (he's now quite famous here in The Netherlands). He used a system with pink colored post-it notes to keep track of his story lines, yellow post-its for quotes and green post-its for general ideas. His desk used to be a nice collection of post-its, and he would regularly send the entire class away to work on his novel. (He'd be really startled when the class entered his classroom, as if it was a large surprise that he'd have to teach us french. "Eeehm... I'm busy. Go away!" he'd say).
Bottomline: use the simplest tools you can and don't let things (or classes!) distract you.
At first I recommend no tooling. Use your favourite editor and start. Once you have content you can figure out what tool(s) you (might) need. Let the content and needs drive the tools - you might find your use case change as you write.
I was trying to figure this out for a piece of non-fiction which isn’t technical. I wrote it in Emacs using markdown and it proved to be hard to collaborate and get feedback from non-technical people. I looked at Dropbox Paper and Notion since they also supported markdown and those were also hard to get suggested changes. I looked at Word and document sharing and although that was better it had a few problems with OneDrive file sync even though I really liked the Office app on the phone. Finally, I ended up in Google Docs. It is simple, I can collaborate and it syncs readily. Also, the sidebar table of contents is nice to jump to different parts of the book easily. Sure not markdown but for my current needs since I’m not putting any code in the doc it is totally fine. To be honest I don’t know why I went through all the hurdles. Once it is closer to done I may move it to a markdown file again.
I was similar to this. Wrote in Markdown, eventually ended up in Google Docs. But kept my source in markdown.
You can use Pandoc to generate PDF's then send out pdfs via Google Drive so people can comment and add suggestions. This was really useful for proofing, but having to pull up two screens and make changes to source instead of the annotated version was a bit painful.
Scrivener. It's biggest advantage over something like Microsoft Word is that a Scrivener project is basically a custom file system for your manuscript, making it incredibly easy to keep chapters and sections in separate files (for speed, focus, navigation and alternate drafts) and combine them seamlessly when necessary.
Word .DOCs are sluggish to navigate when they get long, tempting to get sidetracked when you're supposed to be fixing a specific chapter, and don't provide a convenient place to stash meta-data (notes, outlines, scrap, alternate drafts, etc.)
If you are okay with using markdown, I have a post on how to use pandoc to generate pdf/epub [0]
I also include links at the end for other flows like Jupyter Book, Asciidoctor, etc. Markdeep [1] might suit you better for a simple solution that allows diagrams, equations, etc.
If you use Windows, take a look at Jutoh.com. It's commercial but not very expensive and excellent for creating .mobi and epub books. It's strength include support for images, tables and source code listings and it has excellent compatibility checking.
The author Julian Smart is also the creator of WxWidgets and Jutoh is very fast at compiling Ebooks. He is also very good at support; I suggested a feature and he had it implemented in a couple of days. I created a 350 page non-fiction ebook.
Is there any code in the book? If so, are they fairly short snippets, or do you build up longer scripts and projects over the course of a chapter or more?
I like to use Plain TeX (with vim as the text editor), although you might prefer something else. But, perhaps there would be another question: What kind of book are you trying to write?
You DON'T want to spend writing time doing any formatting and playing with computers ... that's an easy was to burn lots of time. Get the ideas (words & pics) clear and complete, then the formatting is quick.
And whatever you use, it should do everything with styles, not manually selecting bold-for-this and sans-for-that - that's just a waste of time (so avoid MS).