Ada parameter modes in, out and in out: what do they guarantee and how are values passed?

The modes describe the direction of information, not the mechanism. in, the default, means the caller supplies a value and the parameter is a constant inside the subprogram. out means the subprogram supplies a value; the incoming value of a scalar is not used. in out means both. The compiler enforces this: assigning to an in parameter is an error, and the actual for out or in out must be a variable.

Since Ada 95 you may read an out parameter inside the body, but until you have assigned it, a scalar holds an undefined value.

How the value travels depends on the type, not on the mode. Elementary types (integers, enumerations, floating and fixed point, access values) are always passed by copy: copied in for in and in out, copied back on normal return for out and in out. Tagged types, limited types, tasks and protected objects are always passed by reference. For other records and arrays the compiler may choose either, typically by size.

So your Integer is copied back at the end, while Status_Record may go either way. A correct program must not depend on which.

Two consequences follow. If you return without assigning Value, whatever the local copy happened to hold is copied back, so the caller's previous value is lost and replaced by garbage. A compiler may warn when an out parameter is never assigned, but an omission on only one path is easy to miss, so assign a safe default at the top.

If the procedure is left by an exception, by-copy parameters are not copied back and the caller keeps its old value, whereas a by-reference record may be left half updated. If that matters, build the new record in a local variable and assign it in one statement at the end.

On functions: before Ada 2012 a function could only have in parameters, which is why older code returns several results through a procedure with out parameters. Ada 2012 allows out and in out on functions as well, though many teams still keep functions free of side effects.

Also avoid passing the same variable to two parameters when at least one is writable, as in Swap (X, X), or passing a global that the subprogram also updates directly. Because the mechanism for untagged records and arrays is the compiler's choice, such aliasing can behave differently between compilers or optimisation levels.

If the code is analysed with SPARK, these rules become checked facts. Flow analysis requires every out parameter to be assigned on every path before return, reports reads of uninitialised data, and rejects calls where writable parameters alias each other. You can also state the intended data flow with Global and Depends contracts, and the tool verifies that the body matches them.

That turns the questions you are asking into errors found before the program runs, rather than conventions that reviewers have to remember.