Hi Ihor,
   Chiming in here with a slight variant on what
others have said. Best!
Tom

I don't think this should be handled at the syntactic
layer at all. The empty string block language should
be syntactically valid with any special behavior
needed being handled later.

Linters could treat it as a warning/error though,
but the parsing is made significantly easier if
the empty string is present allowing the grammar
to be fully closed and regular.

Thus, I don't think we need to make this a syntactic
error or pun a src block without a lang to another type.

I think we can add an implementation for when the
block language is the empty string. This keeps
the grammar regular by removing a special case.

I assume that internally the empty string block lang
would mostly call the example block codepaths,
except that it should probably issue a warning or fail
if someone tries to org-src-edit the block so that we
can alert them that they are missing the lang.

Treating src blocks missing a lang as paragraphs is
incorrect because according to the syntax spec they
are syntactically still blocks (greater or lesser depending
on your inclinations).

I think the general principle we want to follow here is
that a block (or any entity in general) should not lose
its type because some part of its syntax is malformed
(I have made similar arguments about property drawers).

That is, if something starts with #+begin_NAME stuff
and there is a corresponding #+end_NAME, then it
is a block.

The choice of how a src block without a lang should
behave is a bit more complex as there are multiple
consumers of src blocks that make different assumptions.

As mentioned above. I think that if a block is missing the lang
we could think of it instead as the null language. If we have the
:var language because someone has other contents on the line
they have a well formed src block, but will get a different error
because there is currently no known language ":var".