What are you looking for in this answer? To directly answer, simply “yes.”. That's all you asked.

Regardless of if you think it is usual or not, in practice many games and many game engines have an abundance of these systems. On-screen messages and visual logging with text and charts and menus within the game. External windows which are fully graphical. External windows which are entirely text and interactive. External windows which are text logs which can be captured and redirected. Log files which are fully timestamped, automatically rotated, output in formats such as HTML or XML or plain text, both logging remotely and accepting debug commands across the network, and all of these systems are configurable for a wide range of in-game systems and range from high-verbosity logging to quietly reporting warnings and worse, to only making a chirp on fatal errors.

When you work in Unreal or Unity or other major game engines it is quite common to get some or all of these at once: Live metrics visible to QA and developers displaying charts, text, interactive menus and adjustment tools, and more; interactive consoles directly in game; plain text windows with logging and interactive command prompts; and log files recording everything you ask at runtime. This is in addition to tool windows you may have open by the tools themselves, physics debuggers, networking debuggers, animation debuggers, game script debuggers, and more.

Is there more to your question?

There're multiple types of such a system in every good game engine. A profiler is used to output runtime logs of the code to any backend, a log system is supposed to collect message the developer set to apear at a given point, then you might have other information depending on the type of game.

In any case you should take care of performance and not blocking your code for too long while handling those data creation or else your code will behave quite different in debug vs. release builds.

However, what I did for profiling was to declare a fixed number of threads that can create profiler information. Then each of those threads has it's own queue and wether it is on-time profiler or just a recorder, the information is handled from a dedicated messager thread.

For our in-game console this was a bit more tricky. It works quite the same as the profiler solution but instead of sending data via UDP, we have different log channels to file as same as to an in-game console. The console is just an R16 texture with 32x64 pixel. Each row is a line on screen and each column is a character to display. The second half of the R component is a color constant to print the character in. Then we have a shader that takes a fixed size 128x128 monospace character texture and translates the provided character index into the character font and color on screen.

This is the best performing way I could think of to handle such kind of debug text.

Our console is also able to take commands. For this we have a set of functions registered in the engine core. Those will be mapped by string-hash to a command typed into the console and then parameters are parsed into primitive types like bool, int, float, char and string, one after another until either all required parameters meet the proper type or a type is found that is not included in the parameter list and the entire command is rejected.

We then have a system that is some kind of reflection, providing RTTI information about functions and their parameter's and types. The same system is designed to perform what isan anonymous call, passing an array of type void** as the parameter definition and have the delegate that was create in beforehand handle the lookup based on a template