In keeping with the way Layouts now have the ability to use a Long Name and a Description, it would be really useful if actual tables could allow Columns to have longer names, or descriptive attributes.
With more complex tables that have many columns, there is no easy way to describe the true rationale for a column. By providing a description of the column it could help many users understand the purpose (or expected data) for a specific column.
While space is much tighter in a table, a way to display it might be an icon 
that can be clicked/hovered for more detailed description/instructions.
It could also be displayed whilst hovering (but this won’t work for mobile).
Regardless of how it might be displayed, I still think it’s a good attribute to have. It could also be used in the Layouts (where currently, a Layout seems to allow such an attribute on a per column/layout basis which I find a little confusing). Surely a column has a purpose or description, and that purpose is consistent regardless of UI presentation (Layout). There is an argument that a Layout MIGHT need to describe the same column in a unique way for that Layout, but by default, it could share the common description from the actual Column. As things stand right now, if you want to apply a description to a column, you can do so in a Layout, but you have to repeat this for every Layout!
What I’ve found is that columns have different purposes for different types of users in different contexts. Or at least, to the extent that the description is used as a way to communicate instructions, those instructions can vary depending on the user and context. I actually like them being unique per layout (but would not be against an inherited default that could be overwritten)
I think this is 100% true.
Sometimes I want a column to say [Input Date of Arrival] other times I want it to say [Arrival Date] other times I want it to say [Date Inputted By User Upon Receiving the Package]. It depends on who my audience is.
If the data input user is looking at it, it’s probably [Input Date of Arrival], when the dashboard user looks at it it’s [Arrival Date], and when I’m looking at it on the backend I want [Date Inputted By User Upon Receiving the Package].
I may have multiple different measures of “arrival date”, a RowModified(thisRow.[Item Status]), one that is sent to me by Amazon through Zapier, and one that is logged by the user. All of those measure information that could easily be called “Arrival Date” from a frontend users perspective, and in different cases they would be perfectly meaningful to a user given their context.
As a final example. If you order a package and it says, “Arrival Date” next to a date in the future, you know that’s the date it will arrive. On the other hand, if you are looking at an inventory log and there’s a column that says, “Arrival Date” you know that’s the date it did arrive. But, importantly, “Date it Will Arrive” and “Date it Did Arrive” are often not the same (due to delays or inventory issues) and therefore represent the opposite case: multiple different columns that could have he same display name.