TL;DR - No: As their name explicitly states, behavior packs give us the ability to modify the behavior of minecraft-bedrock-edition. As a result, they are not, in themselves, modifications to BE. They allow for the customization of minecraft-bedrock-edition (emphasis mine):
Add-Ons are the first step on our journey towards bringing even greater levels of customization to all editions of Minecraft. They allow players to transform the look of their worlds and even change the behavior of mobs. For example, you can change the blast radius of a creeper, or the texture it’s wearing.
Note: See the official Minecraft site on addons for more details.
My strongest argument against behavior packs being called modifications, is that we are limited in what we can modify, even with the scripts we can create. We have been given two methods of modifying the behavior of the game:
- Data Manipulation
We can also create functions in behavior packs, but these are really just glorified commands.
With the common behavior packs, we can see things like the ability to:
- Adjust the scale of a wolf.
- Allow creepers to start fires when they explode.
- Change the loot table for cattle.
The aforementioned examples all rely on a very concrete implementation within the code of BE that looks at the JSON data within resource and behavior packs. So by nature, you're not modifying BE, you're modifying the behavior of objects within BE based on data alone. This is also true when creating entirely new entities.
One might think that the client and server side scripts could be considered modifications, but they also rely on concrete implementations, and as a result simply adjust the behavior of actions. As a result of the ingenuity of the developers, we can:
- Teleport players.
- Define how long lightning and thunder will last.
- Get data about a block at specific coordinates.
- Create and invoke custom events.
Using the client and server side scripts give us much more power over the behavior within BE, but not the ability to truly modify it. For example, if we listen for a block being placed in order to perform some other action (such as making lightning strike that position), the block will still be placed, you can't stop that from happening. You can delete the placed block immediately after it is placed, but you can't prevent the underlying code from placing it in the first place.
Counters to @Joachim's Points
Per request of @ExpertCoder14, this question was answered by @Joachim, where they took the stance that:
Behaviour Packs are not part of the base game. I think that logically excludes them.
Contrary to this point, behavior and resource packs are both part of the base game. If you download the official vanilla packs (bottom of the page), you're looking directly at what is shipped with the title.
They also stated:
That functions are considered on-topic might have to do with their likeness - correct me if I'm wrong - to batch files and shortcut parameters, which are not that different from using in-game console commands and don't require any third-party software.
Behavior and resource packs fall under this same description. The issue is that they are much more verbose and even the common Minecraft function/command user is going to avoid that level of data for quite some time, simply because it's a daunting amount of information, lacking in documentation, and a rather niche topic.
They also made a point related to the linked question sounding like GameDev material:
In the case of the question you refer to: the OP is talking about "coding an addon". That sounds like unmistakable GameDev material to me.
The question that @Joachim is referring to, while also poor quality, is misphrased in my opinion, and as a result, also misunderstood:
I am currently coding an addon for Minecraft PE, but I don't know how to code an item that acts like a daylight sensor (i.e. it emites a redstone signal when there is light). Help would be greatly appreciated.
The OP of said question states that they are "coding" an addon, but haven't actually supplied any form of source code that would solidify that fact. In reality, you don't "code" an addon, you create one, and it either contains scripts or it doesn't.
Minecraft is a game. Modding a game is developing new experiences for the users of the game. Modding is thus game development. Game development is the core of GameDev.se. We can conclude that Minecraft/Bukkit modding, and game modding in general, has its place here.
Per request of @ExpertCoder14, this question was asked by @Fabian Röling, where they stated that (emphasis mine):
MCBE's behaviour packs are very similar to datapacks, they are often seen as MCBE's (not quite as powerful) equivalent to MCJava's datapacks. But by now we've gone quite far out of the realm of "do stuff in the game", because this is about programming in a regular, non-Minecraft-specific programming language, outside of the game. But it is still something that is interpreted by the game, just like functions in a datapack are.
I'm not so sure that we're outside of the aforementioned realm, simply by working with a behavior pack. I think more context is always going to be required in order to determine that.
As for the remainder of the behavior pack (over 98% of it), more than 99% of questions are going to be related to data manipulation. The 1% that doesn't fit this description are going to be how to tie events defined in scripts, to entities defined in the behavior pack. However, with that, even those questions are technically a fit for Arqade because they can be easily described from plenty of examples in the vanilla packs, which, are included with the game at launch.