The bin file does not have any signature, which is intentionally designed to facilitate direct concat or weight splitting. However, as you said, it is not convenient for Netron to distinguish its type, and I often notice this problem when using Netron.
I think adding a signature will break compatibility. In the latest ncnn model conversion tool pnnx, https://github.com/pnnx/pnnx , the suffixes are changed to .ncnn.param and .ncnn.bin (you may notice that there will also be pnnx.param and pnnx.bin, aha)
Some existing old tools, such as onnx2ncnn, still use the param/bin suffix. We have printed deprecation information in the tool to guide users to migrate to pnnx.

Thank you for your great work, Netron, it is very useful!

Is adding a signature to the end of the file an option? The goal is to limit the number of .bin files that cannot be clearly identified. For example, users sometimes mislabel other file types as .bin (ONNX files or TensorFlow Lite) and it is challenging to investigate these patterns when there are many .bin files with random data that cannot be identified.

The bin file is a concatenation of the original weight data. Adding extra information at the end of each bin file will invalidate the concatenation. Directly concatenating two bin files will produce an invalid bin file.

Also, even if you can tell that this is a bin file of ncnn, using netron to open an independent bin file should not work, as it does not contain any information about the model graph. Users should drag the param and bin files into netron together to view the weight data.

Also, even if you can tell that this is a bin file of ncnn, using netron to open an independent bin file should not work

Users try to open individual files. If possible in the desktop version, the app is trying to find the relevant files. Other frameworks generally allow for this or have been updated not to cause conflicts. It's a limitation specific to ncnn.

For context, the goal is not to enable ncnn to work well. The cost of maintaining ncnn support is larger than its benefit so removing ncnn support entirely would be an easy solution if that would solve the problem. The challenge is more that incorrectly identified .bin files mask other bugs as users often use .bin freely for ONNX or TensorFlow Lite formats which are used more frequently.
The bin file is a concatenation of the original weight data. Adding extra information at the end of each bin file will invalidate the concatenation. Directly concatenating two bin files will produce an invalid bin file.

How is this concatenation determined when using multiple bin files? Only the first .bin file would need to get identified. Is there an example how multiple .bin files are used?

The concatenation of .bin files allows multiple model weights to be combined into one model weight
cat a.bin b.bin > out.bin
.param content is human-editable text, so it is also easy to append directly.

If a signature is added at the end, the signature of a.bin will be left in the middle of out.bin , which will violate bin compatibility. I know this can be done programmatically to achieve the correct merge, but this will break existing workflows and cat scripts that users have written.

I don't want to break my users, and I guess you also want to keep more model support to avoid users having the experience of "Huh? Why doesn't this work suddenly?".

I know that using the .bin suffix without any signature is ambiguous, which brings you maintenance troubles. I recommend switching to the new .ncnn.param / .ncnn.bin suffix matching, which is simpler and more straightforward. To avoid conflicts, the ncnn model conversion tool has also been avoiding the use of pure .bin suffix for more than 2 years and will continue to do so.

The concatenation of .bin files allows multiple model weights to be combined into one model weight

Are multiple .bin files supported by the runtime or is this a workflow to create a single .bin file by merging raw tensors?

The reason for merging into one .bin is not because ncnn can only load one .bin file, but because the user has a purpose.

When distributing applications, developers tend to distribute one file rather than multiple files, especially for several highly related tasks, such as face detection and face feature extraction, or different stages of a task. This makes it easier to manage by task and obfuscate the process to prevent being cracked or having insight into its usage.

I found that this demand is so common that a few years ago ncnn implemented a special tool to merge multiple models [1]. Its principle is to simply merge multiple .param and .bin files. It is also based on the existing rules and cannot handle additional signature bits, which means it will also be broken if a signature is added.

[1] https://github.com/Tencent/ncnn/blob/master/tools/ncnnmerge.cpp