Seriously though, are we running off the rails here? Are we going back to the bad old days of perl "page generators", just replacing a dozen CPAN commands with a bunch or yarn's, gems, and npm's instead? I'm starting to wonder.
I spent the first five years of my career advocating for replacing table layouts with CSS, and finding ways to do just that.
My point is simply that we seem to have gone overboard.
Part of that movement was towards what we called "semantic" markup. Wrapping your content in HTML tags that describes what the content is for (a heading, a list, etc) instead of how it should look (bold, larger font).
One of the reasons that tables were terrible for layout was that with tables you had to use markup that meant different things than what you were trying to accomplish. Among other things, this badly screwed with screenreaders and other software parsers (crawlers, including those of the major search engines; and scrapers).
But for actual tabular data, HTML tables are the semantically correct markup. They work well and can be parsed correctly. The point of the semantic markup movement was never to completely remove tables from our vocabulary. It was to return them to their proper use case.
While we did manage to come up with CSS alternatives for nearly all the table based layout features, CSS Grid is the first option that gives you the full power that tables offered (and more) for the grid-based layouts that have been a staple of graphic design since the creation of the first coffee table book.
But this package reminds me of the straw man argument that some old school developers used to bring up when we encouraged them to learn CSS for layout: "if we get rid of tables, we'll have to come up with insane workarounds for displaying tabular data".
Well, someone just did.
In my experience with React, this kind of approach produces much more readable and elegant code. And also less code. And as long as the configuration objects are simple and readable like these, the problems with it are not serious.
It's true though that when your needs get more specific and complex you will surely find you need something not included in the component's configuration options. In those cases some components will let you specify custom things, which may or may not be enough.
Then it's trivial to reuse that configuration and iterate over them creating the table yourself.
Most tables I've done could easily be written with this component. Most of the time I actually do something very close to its configuration objects, and then iterate over them with a `map` to create the `td` and `tr`. This allows me to separate concerns more clearly.
(I don't know about using css-grid instead of the old tables. Really, I don't know css-grid well enough.)
 The OP's let's you specify a custom renderer for particular columns. That won't solve everything, but will do for many cases.
I agree that these are the main issues with using this kind of component. However, most of the time there is no need to fork the component and, if you actually need things that the component doesn't allow, then it's the time to do it yourself. Because that doesn't always happen, if the component is easy to use it often is worth to go with it and only do the additional work if you need it.
> or the configuration expands to be its own little akwards DSL with very surprising edge cases.
This is the crux of the matter. However with this particular library, the configuration is extremely reasonable, simple and readable. It would be no problem to refactor the code to use the very same configuration to create your own table.
Would help if you added more/different examples to show what else it can do beyond that first example.
> "Please don't impute astroturfing or shillage. It degrades discussion and is usually mistaken. If you're worried about it, email us and we'll look at the data."
> "Please don't complain that a submission is inappropriate. If a story is spam or off-topic, flag it. ... If you flag something, please don't also comment that you did."