I've created a test file with links and images and test text to try and replicate the fault. Follow the steps in the InDesign file attached.

Put simply, text – whether it is UTF-8 or UTF-16 can import unicode characters that are meant to represent emojis etc, and this is demonstrated in the test file. While not in the minion character set, I've created a GREP style that looks for unicode characters and changes them to apple color emoji. That bit works.
What does NOT work is when importing the text as part of a data merge... instead the unicode characters are completely skipped.
Links to the testfile are here: https://www.dropbox.com/sh/32graq18jww5itp/AAAu0Y2bJnCiXjseSTBBFLcJa?dl=0

InDesign does checking of hyperlinks to see if they are valid and indicates the result in the hyperlinks list with a green dot (good) or a red dot (bad).

The problem is my document has 500+ hyperlinks to my website and when Adobe tests these hyperlinks (when I open up the hyperlinks list dialog), it swamps my website with hundreds of hyperlink hits all at once and triggers the denial-of-service-attack IP banning code on my website.

The end result is any time I'm editing hyperlinks in my Adobe InDesign document, I get banned from my website! When I check the server logs, it shows the source being an Adobe app at my IP -- which is InDesign of course.

You need to add an option in the InDesign settings to throttle hyperlink testing by adding a delay between each link test ping. Default it to zero but let the user set a value in milliseconds to delay each test ping. Adding 1000 milliseconds would make each test ping get fired at one second intervals, for instance. Allow a max of 360,000 milliseconds, which is 6 minutes delay between pings.

Your programmers need to keep in mind not everyone has a half-dozen hyperlinks in their documents. Get them to think through what happens in hyperlink testing if the document has 1000 hyperlinks in it, all deep links to pages on a single website -- and they will realize what a monster they've created by not allowing a user-specified per link test delay value.

When I cut and paste URLs from a text document into the hyperlink dialog box, I can accidentally get a carriage return included. InDesign "includes" the carriage return in the one-line dialog box field but gives no indication that it's there.

Once I export the InDesign document to a PDF and then click on the link in the PDF, the link shows with a %0D at the end and it fails with a 404 not found.

This is extremely annoying because InDesign gives no indication that the carriage return is there with its one-line link dialog box field.

What should happen is InDesign should truncate control characters at the end of a URL. It should also truncate spaces at the end of a URL because we've seen %20 show up occasionally as well and that also can't easily be seen and causes the URL to fail. Have your programmers truncate any character at the end of a URL that is ASCII 20 or less and you will be golden!

When a Running Head text variable is generated, under certain (common) conditions, a double-space is inserted where a forced linebreak is used.

To reproduce bug:

1. Insert a Running Head text variable into a master page running head position.




2. Specify the first instance of, say, Level-One paragraph style.




3. In a multi-page text flow, insert a Level-One styled paragraph with enough text to force a line wrap.




4. Within the Level-One paragraph, insert a Forced Line Break (FLB) character.




5. Scroll text back and forth to force update of the text variable display.

Result: On the page containing the Level-One paragraph, the running head will display a space where the FLB would be. On subsequent pages, the running head variable is expanded with NO space in that position.

If you ADD a space in the Level-One paragraph, before or after the FLB, the first instance of the Running Head variable will contain TWO spaces, and subsequent instances will contain only ONE space.

Thus, there is no viable work-around for this bug.

I have attached a file illustrating the problem in a Spread layout. Note that if the first instance of the Level-One style is on the left-hand page (and the running head is on the right-hand page), the problem does not occur.

1. Affected: InDesign CC all versions that are working with CC Libraries.
   Tested with InDesign CC 2018.1 and InDesign CC 2019 version 14.0.2.324 on Windows 10. InDesign versions on Mac OS X are also reported.




2. Steps to reproduce the issue:
   Do a new CC Library.
   Add TIFF images saved from PhotoShop CC 2019 to the new library.
   Two options how you can do this that I know of:
   A. Drag the files from your file system to the open and empty library.
   B. Use Adobe Bridge CC 2019 to drag files to the open library.




3. Expected result:
   If I want to use an image TIFF asset in my layout and place it on the page from a CC Library the placed image should show up as TIFF image with all the right properties, like the right color space, original resolution etc.pp.




4. Actual result:
   The placed TIFF is converted to PNG, color space is always RGB, regradless of the original. Always indicating transparency. Even if the original file stored in the CC Library has no transparency at all.

More details can be seen in this discussion at Adobe InDesign User Forum:

Bibliotecas CC - Indesign convierte imágenes TIFF en PNG
franp30034553 Jul 16, 2019 11:02 AM
https://forums.adobe.com/message/11168505#11168505

Regards,
Uwe Laubender
( ACP )

PS: We can see the same issue with Adobe Illustrator.

PPS: Also did a bug report at Adobe Bridge Uservoice.

https://adobebridge.uservoice.com/forums/905377-report-bugs/suggestions/38165185-tiff-images-added-to-cc-library-are-considered-as