It would look screwy if allocate() were a subroutine. Instead of something simple and intuitive like
allocate( a(-9:9,-1:1), b(n), c )
the subroutine version would need to look something like
call allocate( a, [-9,9,-1,1], b, [1,n], c, [] )
where the zero-size array [] would be required for a scalar allocatable. I’m ignoring the source= and mold= optional arguments.
I think deallocate() could be a normal looking subroutine, but that would probably have caused some confusion since it would no longer be symmetrical within the syntax with allocate().
The move_alloc() intrinsic works pretty much like a normal subroutine. It would be a little difficult to replicate in fortran code because of the arbitrary type+kind+rank aspect, but otherwise it behaves the way a subroutine is expected to behave.
It would simplify a lot of my code if allocate() had an optional argument to trigger conditional reallocation of an existing array. Say something like
allocate( a(lb:ub), conditional_reallocation=.true. )
If a(:) is already allocated with lower bound lb and upper bound ub, then nothing happens, the array is unchanged. If a(:) is already allocated with the correct size but with different bounds, then the bounds are changed but the contents of the array would remain unchanged. If a(:) is already allocated but with a different size, then it is deallocated and reallocated with the new size and bounds. All of this can be done now with some trickery, but these common operations should be a standard part of the language.