From @Samuel Kong:

Here's my version of the explanation on the problem:

The root problem is that when the user types something, we are not saving the original text that the user typed in. Instead we are changing the value - in this case we're replacing newlines with <br /> (or \n). This creates two problems. As an example, let's assume that it's saved as <br /> (although this also applies if we save as \n):
We don't have an escape in case the user wants the literal <br />. So a user who types <br /> will actually see this turned to a newline in some situations.
When we output the text, we often need to output the text differently depending on the context. If we output the text inside of a <div>, <span>, etc, we don't need to change the text. However, if we need to output the text inside of a <textarea>, we need to change the <br /> to \n. And if we need to output the text in a <input value="">, we need to remove the <br />.

This is the problem for this ticket. We're using the same code in multiple places (e.g., Kaleo Designer and DDL) so it's always outputting the user's input the same way. However, we need to output the user's input differently depending on context. This is also why the test case is wrong. We're assuming that that output context is always the same, but it's not.

Here's an concrete example. User types in:

This is automatically changed to:

If we use the outputFormatter, it will change the value to:

Note that \n here is not an escape sequence. We are actually storing a string that is 8 characters long here. Regardless of whether or not we use a formatter here, the point is that we have lost the user's original input. Now when we try to display the user's input, we'll need to convert what we saved: For example, for a textarea, we need to output

But for a <div>, we need to output

So the output needs to change depending on the context.

The proper way to do this is to always store the original text. The text should than output based on the context. However, I'm thinking we can't make this change for 7.0 since such a change will break existing installs, but correct me if I'm wrong on this.

@Jonathan Mak,
I took a look at the failing unit test: https://github.com/liferay/alloy-ui/blob/master/src/aui-datatable/tests/unit/js/tests.js#L483
and I believe the unit test is not for testing the correct behaivor after https://liferay.atlassian.net/browse/AUI-3094#icft=AUI-3094/LPS-69892 is fixed, so I sent pull request to revert the unit test, here are the reasons:

1. https://liferay.atlassian.net/browse/AUI-3094#icft=AUI-3094/LPS-69892 reported an issue that string of <br> (or <br/> or <br />) is displayed in textarea fields in DDL, rather than a correct behavior of visual effect of new line. After my fix of changing to inputFormatter, I am not seeing the bug coming back, which proves my fix is not causing a regression to the issue reported in https://liferay.atlassian.net/browse/AUI-3094#icft=AUI-3094/LPS-69892

2. What the unit test does is that it tests if the code is able to replace <br> (or <br/> or <br />) with newline character '\n', after changing to outputFormatter (because outputFormatter is used to replace br with \n). However the change of outputFomatter is not correct in the first place so the unit test is pointless now.

3. Here is a catch: I went to kaleo designer and tried to type some thing in description field,
with inputFormatter, it displays <br/>; with outputFormatter, it displays ' '(a space). Neither is displaying a visual effect of new line.
There is a big different between description field in kaleo designer and note field in DDL spreadsheet.
The input cell for both is the same textarea editor cell, which supports to input multi-lines, but the display cell for note field is textarea as well, while the display cell for description is text cell(which means it supports one line only). So what I am trying to say in this 3rd point is that: if someone reports there is <br/> in the kaleo designer, we can basically tell them it is normal because the cells are single-lined.

4. To prove my reasoning, here are some interesting functions to set breakpoint:
aui-datatable-cell-editor-support.js/_onEditCell
aui-datatable-cell-editor-support.js/_onEditorSave
datable-table.js/_extractDisplayColumns (used to see the type of each column of cells)

5. And of cause the AUI API says: formatValue() function is supposed to take an inputFormatter, not a outputFormatter: https://alloyui.com/api/classes/A.BaseCellEditor.html#method_formatValue

These changes have been reverted as of 3.1.0-deprecated.20 since they are causing a regression.