Need no strictly formal but normative description.
Terminology.
Semantics based design. No syntax involved at first.
Take S-expression as the target form.

Basic concepts
A conceptual model is needed. The term 'general entity' means the basic overall abstraction which can be treated as generalization of semantics by the language within any use. Since the language would take use of the semantics, a more concrete way should be used. This is called 'name', which is a special general entity. A name is used to denote another general entity. A general entity which is not a name is called an 'entity'.

Meaning of an entity is not limited. No further requirements from the language rules in this base specification.
This design can utilize user code supported by diverse specific implementations of language, which might characterize a set of derived languages or dialects. For example, targeting for programing and documentation needs no modification of code, just to switch a different implementation.

Since programing is a main domain with most requirements, this specification renders some common concepts specified for programing by mapping the terms to subset of the semantic framework above. Note some ter***ike "object" is language specified, so only one of the major interpretation would be adopted.

The code should eventually be text conforming the definition of the formal language, which composed by some kind of elements. Typical element is character. More complex elements called 'token' are allowed. In general, internal structure of these elements is not concerned, unless treated as derived implementation-defined special entities.
There are also requirements for discussing and manipulating the relationship between the code and the semantics. Hence lexical conversions beyond the syntax are essentially needed.
A consecutive portion of code with specific meaning is called a 'region'. The most significant region is 'expression'. Any region is associated with an entity called 'context'. If the context can be literally determined by the syntax construct, it is 'explicit', otherwise 'implicit'. Combination of contexts for same region is also a context.
#ISO C++: declarative region.
A context holds some important properties of the region. For instance, the number of tokens in an expression is an explicit context; an expression can be specified always associated with an implicit context called 'type', which is an entity ruled by a type system.

A name can be 'valid', namely the entity denoted by the name is determined without ambiguity. Generally, the validity of a name is dependent on the region includes it. A region including a valid name is called the 'scope' of that name. Distinct names can share same strategy of validity, so the scope is for multiple names, shortly "the scope". Thus scopes can be classified under the validity strategy. This strategy can be associated to kinds of specified entities.
#ISO C: file scope/block scope/function prototype scope, etc.
#ISO C++: file scope -> namespace scope, also class scope, etc.

Syntax constructing note 1
For syntactic use (as a name), a token denoting an entity is called an 'identifier'. Identifiers at specific scope may be transformed to a sequence of tokens under some lexical rules with no semantic changes in that scope. This is called 'identifier qualifying', and the result is 'qualified identifier', whose use is also a name. A typical way of qualifying is prefixing, namely placing some distinguishable token sequence at front of the original identifier as the 'qualified prefix'.

Deferred.

Editorial note 1:
It is proper to lead users to know the essence of following distinctions:
For (end-)users, language (interface) and its implementation. For example, how to determine which language runtimes are needed and to install them.
For mainstream users (general developers), the syntax and the semantics. Whether the syntax and semantics have totally separated descriptions is depend; but for most languages this distinction should be sensible, since they are adaptive and practical for different aspects of the language, or more precisely, different problem domains. Generally, this distinction has been effective since the language is implemented. Pure grammar is only sound for restricted metalanguages, which is not hierarchical.
For language developers (or language-oriented programers), the metalanguage and the object language(s) it describing. This scene is rare for mainstream programing cases (at least currently), but it is more and more important. Skills of formal specification should be aware for language production, avoiding error-prone syntax and semantics definitions. Though parser generators or some other formal tools have been already popularly used for this purpose, they are only small pieces of cake.

Temporary drafting phase paused to make sync with doc @ YSLib repo.

TBD: merge with pl-doc: en-US/calling-for-language-features.md.

Main specification has been migrated to YSLib user documentation.
The old documentation in the YSLib doc/ directory is kept only for implementations of specific dialects.