General Observations

The code is not portable since it assumes that the input must be ASCII and not all systems use ASCII. The code doesn't seem to allow capital letters for variable names, although that may be what 97 is.

It might be better to allow the program to take arguments such as a file name for input rather than hard wiring the equations into the code.

The code does not consistently use the macro constants defined. There are 2 examples in the main() function:

The value 256 in :

    // Example matrix entered as 4 strings.
    char stringMatrix[NUMBER_OF_RESULTS][256] =
    { "3x + 4y -5z + 6a = 39", 
    "6x + 5y - 6z + 5a = 43",
    "9x - 4y + 2z + 3a = 6", 
    "2y - 3z + a = 13" };

should probably be using MAX_STRING.

The value 4 in :

    for (size_t i = 0; i < 4; i++)
        printf("%s\n", stringMatrix[i]);

should probably be using NUMBER_OF_RESULTS.

The code would be more useful if NUMBER_OF_RESULTS was a variable that was calculated when the equations set was loaded.

Let the Compiler Tell You Where Possible Issues Are

When doing C program development it is always a good practice to compile with the -Wall and -Wextra flags. These flags will help you find possible errors in the code. When I was learning how to program in C on Unix we had a program call lint which helped identify possible problems in the code. I always ran lint on my code. To some extent the -Wall and -Wextra flags have replaced lint.

If the program had been compile with the -Wall and -Wextra flags it would have found the following issues:

/usr/bin/gcc-12   -g -Wall -Wextra -MD -MT CMakeFiles/str2LinearEQ.dir/str2LinearEQ.c.o -MF CMakeFiles/str2LinearEQ.dir/str2LinearEQ.c.o.d -o CMakeFiles/str2LinearEQ.dir/str2LinearEQ.c.o -c str2LinearEQ.c
str2LinearEQ.c: In function ‘seEvaluate’:
str2LinearEQ.c:182:27: warning: comparison of integer expressions of different signedness: ‘int’ and ‘size_t’ {aka ‘long unsigned int’} [-Wsign-compare]
  182 |         for (int j = 0; j < strlen(line[i]); j++)
      |                           ^
str2LinearEQ.c:208:1: warning: statement with no effect [-Wunused-value]
  208 | 3
      | ^
str2LinearEQ.c:208:2: error: expected ‘;’ before ‘char’
  208 | 3
      |  ^
      |  ;
  209 |     char temp[MAX_TEMP];
      |     ~~~~
str2LinearEQ.c:210:23: warning: comparison of integer expressions of different signedness: ‘int’ and ‘size_t’ {aka ‘long unsigned int’} [-Wsign-compare]
  210 |     for (int i = 0; i < strlen(vars); i++)
      |                       ^
str2LinearEQ.c:213:13: error: ‘temp’ undeclared (first use in this function); did you mean ‘mktemp’?
  213 |             temp[i] = 0;
      |             ^~~~
      |             mktemp
str2LinearEQ.c:213:13: note: each undeclared identifier is reported only once for each function it appears in
str2LinearEQ.c: In function ‘seSearch’:
str2LinearEQ.c:232:27: warning: comparison of integer expressions of different signedness: ‘int’ and ‘size_t’ {aka ‘long unsigned int’} [-Wsign-compare]
  232 |         for (int i = 0; i < strlen(vars); i++)
      |                           ^
str2LinearEQ.c:246:19: warning: comparison of integer expressions of different signedness: ‘int’ and ‘size_t’ {aka ‘long unsigned int’} [-Wsign-compare]
  246 |     if (index + 1 < strlen(equation))
      |                   ^
      

Use the Proper Integer Type as an Index Into an Array

Several of the above warnings are about type mismatches between int and size_t. In the C programming language it is better to use the size_t integer type when indexing arrays.

In C, size_t is an unsigned integer data type defined in the stddef.h header file (and other headers like stdio.h). It's used to represent the size of objects in memory. The size_t type is guaranteed to be large enough to hold the size of any object in memory on a given platform. This means it can safely store the result of the sizeof operator and is often used for array indexing and memory allocation. Being unsigned, size_t cannot represent negative values. This makes sense, as the size of an object can never be negative. The exact underlying type of size_t is platform-specific. On a 32-bit system, it's typically a 32-bit unsigned integer, while on a 64-bit system, it's a 64-bit unsigned integer.

Common Usage:
sizeof Operator: The sizeof operator returns the size of an object or data type in bytes, and the result is always of type size_t.
Array Indexing: When indexing arrays, it is recommended to use size_t to ensure you can access all the elements.
Memory Allocation: Functions like malloc and calloc use size_t to specify the amount of memory to allocate.

Code Organization

Function prototypes are very useful in large programs that contain multiple source files, and that in case they will be in header files. In a single file program like this it is better to put the main() function at the bottom of the file and all the functions that get used in the proper order above main(). Keep in mind that every line of code written is another line of code where a bug can crawl into the code.

Magic Numbers

There are Magic Numbers in the bool seIsDigit(char c) function (47 and 58) and in the function void seEvaluate(char **line, size_t linec, double **matrix) (97), it might be better to create symbolic constants for them to make the code more readble and easier to maintain. These numbers may be used in many places and being able to change them by editing only one line makes maintenance easier. In the case of bool seIsDigit(char c) it might be better to use '0' and '9' since these will be more portable.

Numeric constants in code are sometimes referred to as Magic Numbers, because there is no obvious meaning for them. There is a discussion of this on stackoverflow.

Don't Reinvent the Wheel

The C library provides the function isdigit() if the code includes ctype.h. This is much more portable than the current implementation.

Prefer Braces { and } Around Single Statements in if or loops

Some programmers consider this a style issue, but it makes it much easier to read and maintain the code if each in an if, else or loop block is embedded within braces. Extending the functionality of these statements can be problematic when the braces are not used. For a more in depth discussion of this see the first 2 answers on this Stack Overflow question. As one of the answers points out this is true in all C like languages (C, C++, C#, JavaScript, Java, etc.). I have worked at multiple companies where this was required in the coding standard and flagged during code reviews.

Avoid Global Variables

It is very difficult to read, write, debug and maintain programs that use global variables. Global variables can be modified by any function within the program and therefore require each function to be examined before making changes in the code. In C and C++ global variables impact the namespace and they can cause linking errors if they are defined in multiple files. The answers in this stackoverflow question provide a fuller explanation.

If the variable power really needs to be shared between functions make it a static declaration so that it is local to the file.

static int power;

Please note that power is not initialized when it is declared. This can lead to Undefined Behavior if it is used without being defined.

In main you have the following, and it's a little suspect.

    static double resMatrix[NUMBER_OF_RESULTS][NUMBER_OF_RESULTS+1];

    // Turning the coefficient matrix suitable for functions.
    double *pRetMatrix[NUMBER_OF_RESULTS];
    for (int i = 0; i < NUMBER_OF_RESULTS; i++)
        pRetMatrix[i] = resMatrix[i];

It appears you're turning your two dimensional array of double values into a single dimensional array of pointers to double so that you can effectively pass your two dimensional array as double **.

This does avoid the warnings/errors that occur if you try to pass a two-dimensional array as a pointer to pointer, and to your credit it means your data is not segmented all over the place in memory. This is a very common source of confusion for programmers working in C, because a single dimensional array decays in such a context to a pointer to it's first element, but a two dimensional array does not decay into a pointer to pointer, but rather a pointer to array.

Recommended reading on Stack Overflow: What is array-to-pointer conversion aka. decay?

Your best bet for addressing this is not the hoops you're jumping through now but to encapsulate that two dimensional array within a struct. You can then pass a pointer to that struct to avoid copying a larger array repeatedly.

Alternatively, you can use dynamic memory allocation to let a matrix have varying dimensions and use arithmetic to treat a single dimensional array as a two dimensional one.

E.g.

struct DoubleMatrix {
    size_t rows;
    size_t cols;
    double *data;
}; 

struct DoubleMatrix *newDoubleMatrix(size_t rows, size_t cols) {
    struct DoubleMatrix *new_matrix = malloc(sizeof(*new_matrix));
    if (!new_matrix) {
        return NULL;
    }

    new_matrix->rows = rows;
    new_matrix->cols = cols;
    new_matrix->data = malloc(sizeof(*new_matrix->data) * rows * cols);
    if (!new_matrix->data) {
        free(new_matrix);
        return NULL;
    }

    return new_matrix;
}

Also potentially worth reading: Three Star Programmer