There is no such thing as a cell in an .m file. An .m file is a plain text file. Open it up with a text editor and look inside.

Cells exist only in rich-text notebook files, which cannot even be read by Get.

There is no bug.

In my previous answer to you I talked about how to automatically generate an .m file from a notebook file. There, I mentioned that only those cells will be exported to the .m file which are marked as initialization cells. This is probably what confused you.

It is a Mathematica cell. It has a cell bracket. It has cell properties. What is a non-cell?

The image I posted was in direct reply to 2 people asserting that .wl files contain no cells. That is logically equivalent to asserting that everything in a .wl file is a non-cell.

Are you being ironic?

When in Rome do as the Romans do, and this community is insisting that those things you and Mathematica call "cells" aren't really "cells". This community would rather make bizarre claims about "cells" than face the substance of this thread's original post.

This is all nothing but a confusing diversion from doing math.

It started as a straightforward bug-report. Bug-reports are not a plot to divert you from doing math. They're an everyday, integral part of the software-development process. Other communities respond to such bug-reports by straightforwardly fixing the reported bugs.

Cells exist only in rich-text notebook files, which cannot even be read by Get.

Demonstration of non-cells in .wl files which Mathematica erroneously calls "cells":

.m and .wl files... don't have cells.

Demonstration of non-cells in .wl files which Mathematica erroneously calls "cells":

Most of this is a blizzard of confusion thrown at a new user.

Mathematica is not just a programming language. A much better paradigm is that it's a piece of paper, or medium, on which you can write and do mathematics. A very special medium because of its active and dynamic capabilities. Capable for not only doing calculations, but for building capability and the best communication medium of all. And not that difficult to use if new users are not always led up blind alleys.

The statement that .m and .wl files do not have cells is totally misleading. A Mathematica notebook at its most basic level is also a text file, But that is not the level at which most users should or would interact with it. All of these files, .nb., .m, .wl, do have cells. A .m file has a Title cell, (sub)Section cells, Text cells, initialized Code cells and uninitialized code cells where you could retain some old versions of code.

It's easy. Why all this confusion for new and some old users?

There is some documentation on this: AutoGeneratedPackage

As I remember (I may be wrong), earlier versions of Mathematica always offered to automatically create a package when saving a notebook with initialization files. There was definitely an easy-to-discover graphical way to do this. This functionality was phased out for some reason. Perhaps many people found it confusing. Thus today we need to do more work and go through less well documented avenues to make use of it.

I imagine it is very hard to balance the features so that they are sufficiently powerful yet not too difficult or confusing for newcomers. Wolfram definitely puts effort into making the system approachable. Think about features like natural language input, the suggestions bar, the uniquely excellent documentation, and the many available educational materials (multiple tutorials written by SW himself).

Actually, many of us think that by trying to cater to complete novices, Wolfram made decisions that are ultimately to the disadvantage of most other users. One example is dumping everything into the same namespace instead of structuring the system into packages. Another is the large number of new functions that could be trivially put together from a few building blocks ... but make the language feel cluttered and sometimes don't even perform as well as a trivial implementation (example: Downsample, whose performance was fixed recently). Yet another is providing very high level functions that try to do everything, and try to do it fully automatically, but not providing access to the individual underlying algorithms (or not documenting them sufficiently—see how Method options tend to be severely underdocumented). These are of course my personal opinions, but I know that there are many people who agree with the gist of them ...

The good things I observe are that:

• Wolfram understand that Mathematica is a programming language and needs to remain a programming language. Some competitors tried to make their systems accessible with menu-and-button interfaces. Looking at the success and failure of other systems, at this point it is clear enough that Wolfram are taking the right approach.

• They also understand that most users of Mathematica are not programmers, and try to cater to this audience. I think that currently there are more resources to learn Mathematica than ever before, and new users can get help very easily.