You asked several questions one of which was answered in another question and I believe the other answer is only half correct.
If [it being a general DevOps technology is] the case, what exactly [is a buildpack]? And how does it differ from something like a docker image? Or are they the same things with different names?
Yes buildpacks are a general DevOps tech atleast now (you can read why farther down below with the history.) Docker images and buildpacks are two different technologies. Buildpacks produce container images. Docker Images are container images. Buildpacks are hence different then Docker Images, but related to them. But, using Docker there is also a way to produce these images called a Dockerfile. Buildpacks are thus much more like Dockerfiles than they are like Docker Images.
Now I would like to explain the difference between Dockerfiles and Buildpacks. A Dockerfile is usually created by a developer for every app they make. For example, first they pull in a Programming language's docker image (e.g. NodeJS's), then they copy over their files to the container (e.g. the project's app specific code), then install dependencies (e.g. yarn install), then they compile code (e.g. compile typescript code), then they define the way to run the app (e.g. npm start), then the Dockerfile has done it's job and has created the system at a particular state and then an image is created.
Now if you've ever used heroku you know that you don't need Docker or Dockerfiles to run your app you only need your project code and heroku automatically figures out how to create a container image and run your code. It will do things such as see there is a package.json in your project code and apply a Node.js Buildpack to the code to build a container image. That is the magic of Buildpacks.
I am familiar with the term buildpack from a platform called Heroku. But I am not sure if it's a Heroku-specific term, or if it exists more broadly in DevOps nomenclature?
Yes it now does exist more broadly in a sense, and the history of buildpacks started with Heroku; here's a bit on that history:
Buildpacks were first conceived by Heroku in 2011. Since then, they have been adopted by Cloud Foundry and other PaaS such as Google App Engine, Gitlab, Knative, Deis, Dokku, and Drie.
When I google, I see plenty of articles about buildpacks that don't mention Heroku, so I guess it's more general.
Yep. It's general and sometimes when a tech project diverges into several projects from several different companies such as when one tech like heroku's buildpacks is recreated by: "Cloud Foundry and other PaaS such as Google App Engine, Gitlab, Knative, Deis, Dokku, and Drie"; someone or some team is kind enough to give us a single standard to use and this is how Cloud Native Buildpacks was born:
The Cloud Native Buildpacks project was initiated by Pivotal and Heroku in January 2018 and joined the Cloud Native Computing Foundation in October 2018. The project aims to unify the buildpack ecosystems with a platform-to-buildpack contract that is well-defined and that incorporates learnings from maintaining production-grade buildpacks for years at both Pivotal and Heroku.
Cloud Native Buildpacks embrace modern container standards, such as the OCI image format. They take advantage of the latest capabilities of these standards, such as cross-repository blob mounting and image layer "rebasing" on Docker API v2 registries.