It finally died... what's my new computer going to be?

As a manufacturing person there are many capabilities in graphic products, CorelDRAW included that need to remain static or move forward slowly because the evolution of the deployment of manufacturing equipment is slower than software development. 

However if the product is coded properly that shouldn't preclude new features however with Draw, in my opinion it's another story.

A very simple example is the 30,000 x 30,000 pixel limit in images, this is a nothing thing, until you hit it. This limit requires me to have another application, it's peanuts in terms of cost but it's a pain in the butt. No Corel recognized this on offered free PhotoZomm free for a couple of cycles. However when they supposedly recorded during 2019 they failed to remove the issue in their products. No continuity in development.

Another simple example was web graphics, like it or not graphics for web use is a standard today. It took 2 cycles to make it work, it's still a bit convoluted and the process was demonstrated incorrectly on their web site.

Your concept of inter application compatibility is the future but I'm not sure of the value of the base code in the product. When color management was moved from application based to document based it was a Herculean effort. It broke things that (while in the end it made sense) it was unbelievable how complex the change was and how long it took.

I may be wrong but I believe Corel is slowly trying to replace the code to make it more viable. Yes they recorded in 2019 but I believe all they did was make coding their existing outdated coded easier for 3 platforms.

Surely creating reader for the objects in the file isn't earth shattering. That's the place where I'd start.

The issues of swapping things about that might have different size attributes is manageable.

Gets the program back to an enterprise level tool. Surely we all believe in trickle down best code to consumer product?

I've never seen the inside of a Draw file but I would imagine it to be some sort of XML format or easily converted to and from one.

You could go as far as to build in Draw and render on a server as PDF using local and remote linked files.

I'll bet you everything is in place within Draw and the file file structure to do it. And there has likely at some point been a diagnostic tool made for use in house to review file structure errors.

You don't have to make changes to Draw to do this. It can all be done by review of the objects in the file.

You wouldn't need to fuss with linking within Draw, place holder images and text only need the size and other characteristics and some image that is recognizable in thumbnail as what it is.

I'm sure I'm not the only person that uses Draw as a kind of free-form visual database.

Things that can be done within Draw as far as professional publishing goes, it's most going to be fluff going forward as most of the big deal stuff in done.

Things that can be done to a Draw file when seen as a database of visual objects is untouched.

One of these has a lot of bang for the buck and the other is near worthless.

The lack of pixel space is PP is far less of a concern than the s##t curves!

The pixel issue only impacts some specific jobs, the s##t curves impact every job and waste much time.

You always complain about curves. Are talking drawing paths or tone curves?