Too bad there are already common formats supported by nearly every single tool . Though i don't quite understand the logic of not using more than one format, when said format is usually supported by all systems. Why support Autodesks prioprietary format, when a more common format supported by all 3D tools is Colloda, Obj, and Open Game Exchange?

Having existing formats != a workflow.
So you add a collada importer, and tell artists they can put collada files into the engine. Does your importer merge their submeshes, or is that their job? How do you create animation sets from multiple collada files, and do you correct for situations where skeletons between animations and models are slightly different? How do the artists annotate animations with timeline events, such as footfalls? Do you account for the slight differences in how 3DS Max & Blender each choose to write their Collada files (the spec is open to interpretation, extension, and abuse)?
How does the artist select a particular game shader from in their DCC tool? How do they enable shader options, such as parallax mapping? How do you decide which vertex attributes to import from the collada file? If the chosen shader requires a vertex attribute but it's missing from the file (e.g. tangents), do you report an error, or try to create the data yourself? What's the recommended way to import baked normal maps + NBT basis frames without losing precision? How many sets of vertex colours can you support? What naming conventions should artist's use to designate primary and secondary UV sets? Will they create their materials in the DCC tool and export them in the collada file, or will they create the materials later, in your engine? Does the engine automatically create texture atlases when merging sub-meshes of a model, or should the artists manually pack their textures together?
How should assets be created to work with visibility / occlusion / culling systems? Should the artists manually split large models into sub-meshes according to spatial groupings, to allow sub-meshes to be hidden? Do they need to create a separate low-poly occluder mesh? What about a separate collision mesh for the physics system? How are physics materials and audio-materials linked to visual surface materials?
What types of texture layers/channels do your game shaders require - albedo/roughness/metalness/normal, etc? Are some layers optional? Are there naming conventions for these layers? Are the textures DXT compressed by the importer or do the artists need to do it manually? What conventions for specular maps does your game use (specular maps are different for every game as no one seems to be able to agree on conventions for them)? What's the in-engine-preview workflow for texture artists who need to quickly iterate on things like the specular maps? Can they use your game's shaders within their DCC tools for preview purposes, or is there a preview tool, or engine mode designed for texture tweaking/iteration?

Many questions / problems arise from actually trying to produce content for your engine. If there's no solid workflow to create content for the engine, then it's not finished yet.

When you start making a game, even with Unity / Unreal / etc, you need to decide on the workflow that your content creators will follow. Off-the-shelf engines will put constraints on your content-creators -- they'll have their own lists of supported formats, their own naming conventions, material systems, etc, which your content creators will have to adhere to... One major advantage of building your own engine over an off-the-shelf one is that you've got unlimited flexibility in choosing your workflow if you do it up-front. If you don't do it up-front, then you'll be blindly creating the same sorts of constraints completely by accident, which is probably even worse than an off-the-shelf engine. At least off-the-shelf engines have been tested by a large amount of users, so their constraints are probably pretty reasonable.

Too bad there are already common formats supported by nearly every single tool . Though i don't quite understand the logic of not using more than one format, when said format is usually supported by all systems. Why support Autodesks prioprietary format, when a more common format supported by all 3D tools is Colloda, Obj, and Open Game Exchange? Plus for things like .wav and mp3 files... they are under some hard core licences... so using them in a game engine is no go.

Wav is fine, but MP3 decoding/encoding algorithms are covered by patents (having the files exist is fine - the process of decoding them is protected ). However, you use a library like FMOD, they've already paid the licensing fees for that algorithm, so you're free to use MP3 files. That said, if you do use something like FMOD, then you'll likely have a workflow where your source data is in WAV, but then your content build system compiles them into some kind of archive of vorbis files, etc...

Likewise for your collada files -- you would never ship them as part of your game! Your engine's tools would import the necessary data from the collada files and convert them into a much smaller / more efficient format. e.g. A randomly chosen model in my current project is 8MB XSI (source) -> 23MB collada (intermediate) -> 7MB imported (in RAM in the toolchain) -> 4MB engine (compiled to efficient on-disk format) - > 0.5MB engine archive (compressed for streaming). If you make a decision such as "the engine supports collada files", then that's one piece of a workflow -- you also need to make decisions as to what format you'll convert those collada files into, and how/when the conversion takes place (as well as the many, many above questions about how the content of the collada files is treated / constrained).

You have a build system for your code -- what's the build system for content?

Will echo what many have already said.

The engine runtime is the fun part, and also mostly easy, unless you go for challenging state-of-the-art tech, or try to maximize performance. Creating the scene management, rendering and lighting, physics integration, possible multithreading etc. This can still take a lot of time (easily a man-year) depending on your expertise and how much features you're going to add.

After you've got the runtime done, the rest is to make the system usable for actual game creation. Up to this point you probably haven't needed to make any concrete decisions on how the game projects made with the engine are structured, how assets are imported and cooked into a build, how the game logic or rules are inserted and how they interact with the runtime, how the world data is represented for processes like precalculated lighting or navigation data creation, and how to make all the workflows usable for the creators. Now you're going to have to make a lot of decisions which influence what kind of games you can make with the system, and how usable it turns out in the end.

It helps if you can handle 3D modelling yourself so you can continuously test from a content creator's point. In reality working on the runtime & tools / workflow will very likely intertwine, I just separated them to illustrate the difference.

You can also decide to limit yourself to just creating a coder-oriented runtime library (compare e.g. to Cocos2D or Ogre), rather than a full-blown game engine (like Unity). It will still be a worthwhile learning experience, but probably not something that's directly useful as a game creation tool. Getting to the full-blown stage will certainly take man-years.

One challenge I haven't seen any comments on is - depending on the language - is incorporating type reflection and a Metadata system. The reason I bring this up is that it is not simple nor one sided in a C/C++ code base (which I would recommend for an engine - even more so for learning purposes).

The reason I bring this up is because not many have, it offers usefullness, and when incorporated, makes life a breeze when adding new modules. Many have brought up tool chains and the such but have forgotten that to make something - like a great editor, property reflection is extremely handy. For instance it enables easier data binding to your User Interface as well as writing out assets to a file and loading them in later. Other uses is that incorporating reflection, you may get serialization and a network protocol for free. Finally, adding new modules becomes easier if you design an extensible reflection or Metadata system. For instance, incorporating a scripting language becomes simpler when you can look up function and class definitions automatically in code. As opposed to hard coding them to be bound into the scripting language, on top of having to add new bindings with each new class.