The right and left single and double quotes (U+2018, U+2019, U+201C, U+201D) are displaying (and outputting) reversed in InDesign 14 and 15 when bringing in RTL text. I see no way via a style or setting to fix them, I can only use the wrong ones to make them look correctly. It is not only difficult to fix, but it introduces an opportunity for error, means I am editing the text supplied by my client (something that is very bad policy for us), and makes my file underlyingly inaccurate for archiving.
In the attached screenshot, you can seen the the right double quotation mark U+201D highlighted. It is facing to the left in InDesign and (properly) to the right in the Tasmeem add-in tool.

macOS 10.14.6 - multiple computers with us and with customers

We noticed today that extensive user dictionaries are recognized as such by the existing documents, but InDesign (current version) completely ignores them and thus incorrectly hyphens them.

In a special case, a very extensive user dictionary is linked as a symlink (alias) from the Dropbox into the corresponding Linguistics folder in Application Support / Adobe. So far, this worked wonderfully with all versions and has the advantage that adjustments are automatically distributed correctly via the Dropbox.

I tried the following:
the symlink resolved and the extensive dictionary (a lot of entries, 1.4 MB) locally as an independent user dictionary in the above Folder placed (added.txt). As a result, InDesign became extremely sluggish - even renaming to .udc didn't help. It was no longer possible to work and large documents could no longer be opened without InDesign reacting after a while and having to be "shot down".

We have now rolled everything back to v15.0.1, as well as our customers who are working with us on projects with these dictionaries. No problems and InDesign 2020 v15.0.1 works as expected.

Since this misconduct is absolutely not an isolated case here and can also be observed among all customers involved, a pretty bad bug has crept in with v15.0.2, which makes it impossible for us to work with the latest version.

1. Version of Adobe InDesign
   This issue appears in every InDesign versions since footnotes are supported.
   Bug reports / feature requests (from CS3 up to CS6) have been ignored in the past.




2. Steps to reproduce the issues
   given:
   a) a footnote with three text lines
   b) splitting footnotes allowed in the footnote options
   c) keep options: at start/end of Paragraph 2/2 (2 lines at start, 2 lines at end)

Play with the textframes hight so that the footnote is forced to be splitted. It will only split 2/1, not 1/2.

1. Actual result
   The footnots splits with 2 lines in the textframe within the footnote starts and ends with one single line (widow) in the next textframe.




2. Expected result
   a) best choice: hold the keep options!
   (e.g. 2 at start / 2 at end; so don't split a footnote with 3 and less lines).
   b) alternative: make an orphan (full line at the start of a footnote paragraph) instead of a widow; widows are absolutely not allowed (because they ony fill a part of a line, maybe only one word)




3. Test file, screenshot, video or GIF capturing the issue (optional)
   Screenshots appended

As I mentioned here: https://community.adobe.com/t5/indesign/paragraph-bottom-border-overlaps-the-text/m-p/11348398?page=1 the issue occurs when I set a paragraph style with a border and additionally anchor a text frame at the end of it. The border overlaps each time changes to text are made (additional lines, adding a page, deleting a page – everything that causes the flow of the text).

Some similar issue was reported here https://indesign.uservoice.com/forums/601180-adobe-indesign-bugs/suggestions/38784706-footnotes-in-paragraph-borders-style by swapan.

InDesign version ID 2020 15.1.1 and PR Installer (15.1.2.221) on Windows 10. The problem occurs since I have started using a combination paragraph border + anchored text frame (more than 8 month ago). For testing I created totally new files with demo content (Lorem ipsum) and totally new styles created inside the new files. The preferences were reset.

It is easy to manage it manually when you have a single file and only one paragraph bordered. Making any change inside the paragraph adjust the bottom border. But when you have a book with over 30 files with over 30 problematic frames, it is hard to manage it.

When working with Arabic and wanting to have Roman Digits, one needs to choose the "Arabic" digits option.
More option that should be set for Arabic are:
Character direction should be set to "default"
Paragraph direction should be set to "Right to Left"
Paragraph composer should be set to "Adobe World-Ready Paragraph Composer"
Language should be set to "Arabic"
Ligatures should be "On"

BUT
If I type a date that suppose to be presented like this:
9/1/2020
as soon as selecting "Arabic" for language the order is reversed to this:
2020/1/9

As digits has a built in Left to Right direction, all neutral characters between the numbers should get the same definition. This is how it worked until the 2020 update.
Now it looks that all the "/" characters where not effected by the numbers direction and remained Right to Left direction.

Mac Pro (Late 2013)
Software OS X 10.14.6 (18G2022)
Processor 3.5 GHz 6-Core Intel Xeon E5
Memory 32 GB 1867 MHz DDR3 ECC
Adobe Software version: 2020