Arduino serial question
The purpose of the serial input buffer is to prevent data-loss between your program's Serial.read() calls. If you really want to allow long messages to accumulate in it, here is one of many articles that describes how you can increase the size of the buffer in the Arduino core-code. But this is a system-wide solution to one program's design problem - it imposes the memory overhead of that larger buffer on all programs whether they need it or not, or you have to define a new board-type in the boards file (the technique in the above article) and remember to use it for programs that need the larger buffer.

A better approach is to do your own buffering, by defining within your program, a buffer large enough for your largest message (plus the zero terminator), collect bytes from the serial input buffer into your own buffer often enough to not let the serial buffer overflow; then detect when your own buffer has a complete message before you "/* Do stuff */ ".

You appear to be asking about a situation in which you will know in advance what the length of the next message will be; in that case, you can count bytes until you've collected the whole message. 

In other situations, the message may have a terminator such as the NewLine character, or the message may contain the length within the first few bytes, in which case you'd wait for those bytes, convert them to an integer, and use that number to detect the end of message.

Update:


  But it doesn't explain to me really why I can't send it more bytes
  afterwards until I've read the entire input buffer.


I can't offer much help there; I've no experience using .readbytes(); I just read bytes as they arrive until I've got what I wanted. But my notes on it say it "Reads chars into a buffer. Terminates when len bytes have been read, or it times out" (1 sec, I think; there may be a call to change that, too). I'd also consider the possibility of the 64 byte serial buffer having over-flowed; doesn't sound like it but strange things can cause strange things....

"but I rarely work this close to the hardware"
That's the fun and the challenge of embedded systems!