Nothing I said is intended to imply that contractions should be avoided. They are, in any event, a linguistic fact that should be recorded accurately in Wikidata. So, I have:

1. Added forms -F3 ('ll) and -F4 ('d) to L1891 shall. (I've left will for the time being.)
2. Added form -F3 (we shall) to L269709. I don't believe this is correct, but it parallels the existing -F2, so we can get rid of them both later. I added -F3 with the feature "contraction". This is even less correct, but it might help focus future debate.
3. Changed L269709 from a phrase to a contraction.
4. Added a "combines" (P5238) statement to L26909. I tried to add two, but the second merged itself with the first. I've left it as we+shall+will for the time being and
5. Created the discussion page for L269709 explaining the problem. Jura has responded "I think it would be better to have separate entities"... 

Those weeds keep growing... let's think of them as green manure!
On Sunday, 30 August 2020, Thad Guidry <> wrote:
Hi Al.
Contractions that are avoidable would be advantageous in certain cases.  For example:
For Simple English rendering, we might have a rule that says no contractions would be allowed.  This would help others learning a language or simply having smart auto-completion as you type on a Wikipedia page for instance to replace "we'll" with "we will" as an example.  Or a reverse rendering for those that might have their Wikipedia Babel native language for English set to en-N, then you might want contractions in order to avoid verbosity for those that could quickly read and understand English sentences that have them.

In general, there are tons of use cases for renderers that I have thought of and this is only 1 of them, but they all rely on constructors, functions, and lexicographical data stored well and in some standardized fashion somewhere.  Which is why I am always asking about best practices within Wikidata's Lexeme namespace.  I find that I often look for some of the most complex issues to deal with which helps make it easier for me to understand where the gaps will likely be in any system.  Then we can begin conversations on how we'll tackle them.

Looking forward to others' opinions!