I'm guessing that you have availed yourself through the subscription center to log the issues you have with C3D.
That doesn't seem to be the problem. I don't get the impression that Autodesk is failing to receive the feedback they get. The problem seems to be in what Autodesk does with feedback once they get it.
As just one example, let's look at auto-creation of parcels based on roadways. Under typical usage, ROW follows the roadway alignments. And we have different categories of roads - e.g., we may have a "residential" class of road that has typical 50-foot ROW, a "minor arterial" that has typical 60-foot ROW, a "major arterial" that has typical 80-foot ROW, etc. These could vary, depending on our local standards, so there should be an obvious way of creating a "standards" file that contains all this data.
Under a simple usage scenario, we could create the alignments for each of our roads, and declare the category of the road. The ROW would then be autogenerated from our alignments, and Parcels would autogenerate (based on frontage rules, etc.) for the areas that aren't ROW. This is the basic requirement for auto-creation of Parcels.
Now Autodesk gets that requirement, and they create something where we can generate Parcels from our Alignment, but once generated, the Parcels do not change when we move the Alignment. Unfortunately, this wasn't really the requirement - the Parcels should be generated using the ROW as a boundary, not the Alignment. And while they give us a "Create ROW" command, this creates Parcels that do not change with the Alignment. And there is no way to define categories of roads, and assign that category to the Alignment for use in ROW creation, so the "Create ROW" command is also rather clunky.
Now time goes by, and we eventually get another release. In this release, Autodesk has fixed the problem where the Parcels do not change when we change the Alignment, but the ROW generation is still disconnected. So we can generate ROW from an Alignment, but if we move our Alignment, the ROW doesn't move with it. Instead, we get all our land subdivided into a bunch of new parcels by the Alignment. There is no way to avoid this Parcel autogeneration, short of creating extra Sites and keeping alignments on different Sites to suppress the auto-generation of Parcels. This is not what we wanted at all.
More time goes by, and we eventually get another release. Autodesk has heard all the complaints about the unwanted "extra" parcels that get autogenerated from alignments. In response, they create a "Siteless Alignment" collection. The ROW problem is not fixed - it is still not dynamic with Alignments. The parcel-autogeneration problem is not really fixed, we just have a "catch-all" collection that we can use to suppress it. And while we can place Alignments there to suppress the auto-parcel generation, when we do that, we lose the ability to manage Alignments. Normally, we can manage Alignments by putting related Alignments together in a Site, and creating new Sites as-needed, but we lose this ability when we use the Siteless Alignment collection. Also unfortunately, this Siteless Alignment collection has completely different API access, and it creates a lot of bugs when not everything is updated to work with Siteless Alignments as well as normal Alignments. So now there's a chain of extra work for developers all down the line, including third-party developers, all for something we didn't really want in the first place. All we wanted was a way to keep those useless Parcels from being autogenerated - we didn't want a separate Siteless Alignments collection.
See what I mean? We start out with one requirement. Autodesk does something hackneyed. We complain. They patch the problem, instead of fixing it. We complain again. They patch the patch, instead of fixing the underlying problem. Now we still have the underlying problem, and we also have additional problems created by the patch to the patch.
This is only one example - I can come up with several more that are virtually identical.
And the real drawback is how long this process takes. In the example above, this process progressed over several years, and we still aren't really any closer to the original goal. Well, part of the reason for this is that I don't think it's possible to achieve the original goal with the current design of Parcels, so Parcels need to be redesigned from the ground-up before it can happen, but there's no sign of that happening yet. And the longer Autodesk takes to fix core problem features like Parcels, the more stuff they'll get built on top of it, and the harder it will be to change. And if they wait too long, they'll find themselves in the position where it's just too difficult to change, and they're better off dumping the whole thing and starting over, like they did with LDD.
