I agree with John, Rik and Stephen, and dare to post this as an answer.
Can global variables be used in this way? Maybe. The access of global variables is deterministic. After declaring a variable as global, you can read and write to in.
This makes it very hard to debug your code, because the source of the last change of a variable cannot be determined directly. This problem concerns all programming languages and many professional programmer avoid global variables strictly.
You code contains another anti-pattern:
~,~,~, maks_vektprosent_lost_NH4Cl,~,~] = beregn_maks_vektprosent_lost( ...
forste_saltet, andre_saltet, tredje_saltet);
This looks, like the names of the variables contain important information in low level function. This happens, if you write some code, which works for one specific problem only. A gegenral method in programming is to write more abstract codes. This has the advantage, that the code can be re-used for other problems and it can be tested with different cases to validate, that it is working at all.
The strict separation of data, code for processing and GUIs are a smart concept for improving the code quality.
Take a look into the code of e.g. ODE45. Here the state variable is y and the independent variable is t. You can integrate all non-stiff ODEs with this scheme and it does not matter if the inputs are Dollars, bananas, concentrations or meters. t need not be the time. The integrator can be tested exhaustively and is a powerful tool.
Check you code again and think about a more abstract version. Then only the main program knows, that NH4Cl is concerned, while the subroutines work with numbers (which might be concentrations) only. Providing a set of numbers to a subfunction is done by an array, which is easy, clear and compact. This reduces the need to use a bunch of global variables with long and confusing names. And it avoid the cruel effect of typos as in:
maks_vektprosent_lost_kaliumacetat = 0;
maks_vectprosent_lost_kaliumacetat = maks_vectprosent_ost_kaliumacetat + 2;
Here the value of the global variable of the main program is not modified in the subfunction due to the typo 'c' instead of 'k'. With using Matlab auto-completion this happens fast and the debugging is extremely hard, if the code has 100'000 lines.
The good programming practice is, that typos have local effects only and do not influence other parts of the code, which are several level away.
Avoid global variable and provide the data as inputs and outputs:
vektprosent_lost_kaliumacetat = 0;
[y, vektprosent_lost_kaliumacetat] = theSub(x, vektprosent_lost_kaliumacetat);
function [y, c] = theSub(x, c)
Now typos in theSub have local effects only and it is much easier to find problems.