{{#ifeq:{{{inline}}}|yes|<span>{{{1}}}</span>|<div>{{#br}}{{{1}}}{{#br}}</div>

Why can't you use <br> instead of {{#br}} here?

That would place a hard-newline<br> into the output, potentially resulting in undesirable additional white-space, and
crucially would not necessarily insert the context change that the parser (in it's current form needs to see to correctly insert the P opening and closing tag)

using a hard BR over a soft-break would generate :
<DIV><br>{{{1}}}<br>div>
which means that the P wrapping isn't attempted. (That is reasonable in a simple case.)

However If paramater 1 was for example (the line feeds are significant, and as it's an unnamed parameter preserved):

<SPAN style="font-weight:bold> Example: </span>
And this is the continued text on the next line.

Would generate:

<DIV><br><SPAN style="font-weight:bold>Example: </span>
And this is the continued text on the next line.<br><div>'

This works, but will generate additional blank lines before and after the content.

A contributors intent here could reasonably be that "<SPAN style="font-weight:bold>Example: </span> And this is the continued text on the next line. " was one self-contained paragraph.

(continued below)

Someone with appropriate expertise (I don't have it) should sit down and fully document what's actually happening in the parser in various instances.

With BR you get :=

<div><br /><span> content</span> 
content<br /></div>

No paragraph wrapping is attempted. and you get an additional (possibly undesirable white-space line before and after the content. Ugly and not good coding style.

<DIV>
<SPAN> content</span> 
content
</div>

works

Generating:

<div>
<p><span> content</span> 
content
</p>
</div>

which is typically what a template writer wants to happen.

<DIV<SPAN> content</span> 
content</div>

Which is what potentially happens without the soft line break in some situation, doesn't it generates :

<div><span> content</span> 
<p>content
</p>
</div></div>

Which is the "wrapping glitch" in the linked ticket.

From this it is clear that that to have the desired behaviour of wrapping the DIV around the P. The DIV's opening and closing must be on a single line.

Conventionally in wikitext based templates this has been done by inserting 'soft'-newlines..

i.e the template code for a DIV based template might be

<div>
{{{1}}}
</div>

But without directly indicating the 'soft' line-feeds this could in certain situation collapse to

<div>{{{1}}}</div>

which again risks invoking the 'glitch' in the linked ticket depending on what the value of {{{1}}} is.

by having the {{#br}} as an explicitly requested 'soft' line break,

<div>{{#br}}{{{1}}}{{#br}}</div>

the generated output from the template concerned is always going to place the opening of the DIV, parameter {{{1}}} , and the closing of the DIV tag on separate lines, regardless of how that construction might be being produced within a template, or in paramaters which in more complex templates would be a good thing, and in my view less error prone.

(The example I gave in the original posting was much simplified, For a real world example where something like this would assist would be https://en.wikisource.org/wiki/Template:Lang block , https://en.wikisource.org/wiki/Template:Lang and https://en.wikisource.org/wiki/Page:Beowulf_(Wyatt).djvu/115. In Lang the generated code should be

<DIV> 
....
</DIV>

but the way the code is currently written it doesn't gneretae that. Having the magic word {{#br}} to indicate the required 'soft' newline would be a straightforward and easy insertion into the code, and would be less complicated than having to figure out where a line-feed/carriage return/newline should be placed in the template logic to get the same effect, and whose inadvertent removal would change how the template worked.)

As I said initially, in LUA I can append a '\n' where needed. There should be a clean, error-free way to do this in normal templates as well.

DIV{{#br}}content{{#br}}DIV

being less error prone than

<DIV>
content
</DIV>

(with apologies for the convoluted process involved in providing the expanded explanations)

Closing out as based on a discussion , A work around using comment exists..

<div><!--
 This line break is !important! after this comment -->
 stuff here
 <!-- and so is the one before  "<" here --></div>