In 2017, the rendering of execution plans has been changed to use the Number of Rows Read property, rather than the Actual Number of Rows property, as the basis for the arrow width in the graphical execution plan. And based on your reply to https://feedback.azure.com/forums/908035-sql-server/suggestions/32719306-incorrect-arrow-width-in-execution-plans-ssms-17 this was a deliberate choice, not a bug.

Please consider revisiting and reverting this choice.
While I do understand and appreciate the desire to have a simple visual indication of work done by operators in the execution plan, using the outgoing arrow for this is not the correct choice.

One reason is that it's inconsistent. The amount of work done by, for instance, a Stream Aggregate operator, or a Filter operator, is indicated by the width of the incoming arrow, not of the outgoing arrow. Using the width of the outgoing arrow for some operators to represent what is on the incoming arrow for other operators is confusing.
Another reason is that it is confusing. I have been misled by seeing an execution plan where the upper input to a Hash Match join had a much wider arrow then the lower input, so I thought the optimizer had failed to make the smaller input the build input, and wasted time trying to troubleshoot this, until I realized that the actual number of rows returned to the Hash Match was much smaller. I've looked at execution plans where a Filter operator appeared to be very effective, based on arrow width, when in reality the pushed down predicate did most of the filtering and the Filter operator made little change. I've lost time looking at operators that appear to process huge amounts of rows, thinking that they probably ate all the resources, when in reality it was the Scan operator that read thousands of rows to return just a handful, and simply adding an index fixed my issues.
And finally, you are not even consistent within your own tools. In an execution plan plus run-time statistics (aka "actual execution plan"), you prefer to use Number of Rows Read over Actual Number of Rows. Yet, in an execution plan only you opt to use Estimated Number of Rows as the basis for arrow width, and not Estimated Number of Rows to be Read. So now, when looking at an execution plan, I don't even know anymore what the arrow width represents, and it loses all meaning.

I do agree that it's useful to have a visual indication of how many rows were processed by a Scan or Seek operator. But the arrow that represents rows returned by that operator to its parent operator and then processed by that parent operator is not the proper way to represent this.
Why not display a huge discrepancy between Number of Rows Read and Actual Number of Rows as a warning in the execution plan, similar to how SentryOne PlanExplorer does this? (And if you choose to do this, then please ALSO do it for Estimated Number of Rows vs Estimated Number of Rows to be Read).
Or, if you don't want to "steal" SentryOne's good ideas, why not add an icon to the graphical execution plan to represent the storage layer, so that you can represent Number of Rows Read / Estimated Number of Rows to be Read as an arrow flowing from the storage icon to the Seek or Scan operator? Extra benefit of that would be that you could also use different icons to differentiate between disk-based storage, columnar storage, and memory-optimized storage.

But even if you don't use any of the above suggestions ... please stop abusing the width of the outgoing arrow of scans and seeks to represent the number of incoming rows. It's simply too confusing, and I would even rather have no visual indication of rows read at all then the current, totally misleading representation.