Describe the project you are working on:
A story rich, dialogue heavy RPG game / framework.
Describe the problem or limitation you are having in your project:
_RichTextLabel_ has bbcode and custom effects but doesn't have auto-wrap option, ignores grow property, does not resize it's parent container, etc.
_Label_ can do all above things but does not support bbcode formatting and effects.
Both those nodes lack something. Moreover, I can see how they might be really confusing for newcomers, as there is no explanation why Godot needs two nodes for essentially the same job - showing text on screen.
https://i.imgur.com/UfZZK2O.png

Describe the feature / enhancement and how it helps to overcome the problem or limitation:
We need one, universal and consistent node for showing text on the screen.
Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:
Codes for Label and RichTextLabel should be merged under a new Control node - simply named _Text_.
If this enhancement will not be used often, can it be worked around with a few lines of script?:
Is there a reason why this should be core and not an add-on in the asset library?:
It's not just about adding the Text node but also cleaning up nodes. The engine will be easier to use and code easier to maintain with this new node replacing the old ones.
Additonal notes:
There is a big difference between the amount of code lines in Label.cpp and RichTextLabel.ccp (725 vs 3005) which leads me to believe that there must be a good reason why these nodes were created separately. But I still think that combining these nodes would simply lead to less confusion and more understanding from newcomers.
Also, there are things like, the same properties are called differently in label and richtextlabel:
https://i.imgur.com/stvDyS2.png

They are overall so confusing.
Well, afaik, the reason the two are engineered separately is because the fundamental internal structure of the RichTextLabel is much more complex. It maintains a tree hierarchy of "items" that refer to nested blocks of content, e.g. a bolded and italicized link sitting inside of a table that rests underneath an image. The Label node, in contrast, is much more simplified than that, so it's codebase is likely easier to adapt with usability features like the ones you are wanting. Additionally, I surmise that the Label node existed before the RichTextLabel and so rather than hijack and mess up the Label's implementation, they opted to write an entirely new label class to handle rich text.
I think the idea of having a single codebase for text nodes is an interesting idea, as it could provide much needed consistency to their relationship. Basically, if you took the time to implement all of Label's features inside of RichTextLabel, and then renamed RichTextLabel to Text, you'd more or less have what you're asking for.
However, is there perhaps an even better, more abstraction-oriented approach one could take for this? If you're going to take the time to refactor the design of these classes, it might also be good to engineer them to better support other markup languages besides just rich text, e.g. Markdown, ReStructuredText, etc.
If it were possible to define a base class with abstractions to potentially handle a variety of implementations to support rendering different languages, it would be pretty useful. Markdown is part of #139. ReStructuredText would be useful if one wanted to try rendering the godot-docs repo directly in the Godot Editor (though, this would probably be a plugin rather than an integrated feature if done). Who knows what else people might try doing with a Text node that has a good low-level API for building rendered content from a string variable.
@willnationsdev
Basically, if you took the time to implement all of Label's features inside of RichTextLabel, and then renamed RichTextLabel to Text, you'd more or less have what you're asking for.
Yes, that's what I tried to say. We don't need an entirely new node, just a merge of one into another.
However, is there perhaps an even better, more abstraction-oriented approach one could take for this?
One idea I had is that maybe it should behave kind of like Physics Bodies (bear with me).
In this example, the collision node handles the collision detection independently of the body. But they are working together:

With text, it would be like this:

That way, code could still kept separate but now Label only handles size and position, while the child node handles ONLY the text formatting.
Oh, I see. that'd be an interesting approach. You engineer the text format renderer to source all of its positional information from the parent Text node. That could be possible.
Most helpful comment
Oh, I see. that'd be an interesting approach. You engineer the text format renderer to source all of its positional information from the parent Text node. That could be possible.